Hi,
On 2019-01-10 15:56:18 -0500, Tom Lane wrote:
> Julien Demoor writes:
> > [ postgres-notify-all-v8.patch ]
>
> I took a quick look through this. A few comments:
>
> * I find the proposed syntax extension for NOTIFY to be fairly bizarre;
> it's unlike the way that we handle options for any
Julien Demoor writes:
> [ postgres-notify-all-v8.patch ]
I took a quick look through this. A few comments:
* I find the proposed syntax extension for NOTIFY to be fairly bizarre;
it's unlike the way that we handle options for any other utility
statement. It's also non-orthogonal, since you can
Is there a particular format that is needed for the benchmark? Here's a
quick benchmark below.
Unpatched, generating N notifications takes t milliseconds:
N= 1, t= 348
N= 2, t=1419
N= 3, t=3253
N= 4, t=6170
Patched, with the 'never' collapse mode, on another (much faster) machin
> On Mon, Nov 19, 2018 at 8:30 AM Julien Demoor wrote:
>
> Thank you for the review. I've addressed all your points in the attached
> patch. The patch was made against release 11.1.
I've noticed, that cfbot complains about this patch [1], since:
Duplicate OIDs detected:
3423
found 1 duplicate OI
On 10/10/2018 19:42, Catalin Iacob wrote:
On Tue, Oct 9, 2018 at 2:17 PM wrote:
I just caught an error in my patch, it's fixed in the attachment. The
'never' and 'maybe' collapse modes were mixed up in one location.
Here's a partial review of this version, did not read the doc part
very caref
On Wed, Oct 10, 2018 at 5:42 PM Catalin Iacob wrote:
> One way could be to take inspiration from
> src/test/isolation/specs/async-notify.spec and check that
> pg_notification_queue_usage() does grow when repeating the same
> payload with collapse_mode='never' (while for always it would grow).
Sor
On Tue, Oct 9, 2018 at 2:17 PM wrote:
> I just caught an error in my patch, it's fixed in the attachment. The 'never'
> and 'maybe' collapse modes were mixed up in one location.
Here's a partial review of this version, did not read the doc part
very carefully.
First of all, I agree that this is
> Indeed, I have the same and am very interested in this.
>
> > I hope this patch can be reviewed and included in PostgreSQL.
>
> I added this to the next Commitfest and added myself as a reviewer.
> Will try to a review beginning of next week.
> https://commitfest.postgresql.org/20/1820/
Thank
On Tue, Oct 2, 2018 at 7:20 PM wrote:
> I have a feature built around LISTEN / NOTIFY that works perfectly well,
> except for the enormous performance impact to transactions that emit large
> numbers of notifications.
Indeed, I have the same and am very interested in this.
> I hope this patch
Hi,
Back in 2016 a patch was proposed to fix the O(N^2) performance on transactions
that generate many notifications. The performance issue is caused by the check
for duplicate notifications.
I have a feature built around LISTEN / NOTIFY that works perfectly well, except
for the enormous perfo
10 matches
Mail list logo
