|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Julien Demoor <julien(at)jdemoor(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Catalin Iacob <iacobcatalin(at)gmail(dot)com>|
|Subject:||Re: NOTIFY and pg_notify performance when deduplicating notifications|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-01-10 15:56:18 -0500, Tom Lane wrote:
> Julien Demoor <julien(at)jdemoor(dot)com> 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't specify a collapse
> mode without giving a payload string. I think possibly a better answer
> is the way that we've been adding optional parameters to VACUUM and
> suchlike recently:
> NOTIFY [ (collapse = off/on) ] channel [ , payload ]
> This'd be more extensible if we ever find a need for other options,
> * I'm also unimpressed with the idea of having a "maybe" collapse mode.
> What's that supposed to do? It doesn't appear to be different from
> "always", so why not just reduce this to a boolean collapse-or-not
> * The documentation doesn't agree with the code, since it fails to
> mention "always" mode.
> * I was kind of disappointed to find that the patch doesn't really
> do anything to fix the performance problem for duplicate notifies.
> The thread title had led me to hope for more ;-). I wonder if we
> couldn't do something involving hashing. OTOH, it's certainly
> arguable that that would be an independent patch, and that this
> one should be seen as a feature patch ("make NOTIFY's behavior
> for duplicate notifies more flexible and more clearly specified")
> rather than a performance patch.
Given there's been no movement since this review, I'm marking this patch
as returned with feedback. Please resubmit once updated.
|Next Message||Andres Freund||2019-02-03 10:04:51||Re: Implement predicate propagation for non-equivalence clauses|
|Previous Message||Michael Paquier||2019-02-03 09:25:59||Re: [HACKERS] Optional message to user when terminating/cancelling backend|