Re: proposal: make NOTIFY list de-duplication optional

Brendan Jurd <direvus(at)gmail(dot)com> writes:
> On Sat, 6 Feb 2016 at 12:50 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, I agree that a GUC for this is quite unappetizing.

> How would you feel about a variant for calling NOTIFY?

If we decide that this ought to be user-visible, then an extra NOTIFY
parameter would be the way to do it. I'd much rather it "just works"
though. In particular, if we do start advertising user control of
de-duplication, we are likely to start getting bug reports about every
case where it's inexact, eg the no-checks-across-subxact-boundaries
business.

> Optimising the remove-duplicates path is still probably a worthwhile
> endeavour, but if the user really doesn't care at all about duplication, it
> seems silly to force them to pay any performance price for a behaviour they
> didn't want, no?

I would only be impressed with that argument if it could be shown that
de-duplication was a significant fraction of the total cost of a typical
NOTIFY cycle. Obviously, you can make the O(N^2) term dominate if you
try, but I really doubt that it's significant for reasonable numbers of
notify events per transaction. One should also keep in mind that
duplicate events are going to cost extra processing on the
client-application side, too. In my experience with using NOTIFY, that
cost probably dwarfs the cost of emitting the messages.

regards, tom lane