Re: proposal: make NOTIFY list de-duplication optional - Mailing list pgsql-hackers

From Filip Rembiałkowski
Subject Re: proposal: make NOTIFY list de-duplication optional
Date
Msg-id CAP_rww=xRoBfbAqkywCHTs3jDxF9zknh1zLkrJKxZGykRtEHQg@mail.gmail.com
Whole thread Raw
In response to Re: proposal: make NOTIFY list de-duplication optional  (Brendan Jurd <direvus@gmail.com>)
Responses Re: proposal: make NOTIFY list de-duplication optional
List pgsql-hackers
+1

... and a patch (only adding ALL keyword, no hash table implemented yet).



On Sat, Feb 6, 2016 at 2:35 PM, Brendan Jurd <direvus@gmail.com> wrote:
> On Sat, 6 Feb 2016 at 12:50 Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > I agree with what Merlin said about this:
>> >
>> > http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yC10AHU1nFiA1tbHsg+35Ds-oEueUapo7t4g@mail.gmail.com
>>
>> Yeah, I agree that a GUC for this is quite unappetizing.
>
>
> How would you feel about a variant for calling NOTIFY?
>
> The SQL syntax could be something like "NOTIFY [ALL] channel, payload" where
> the ALL means "just send the notification already, nobody cares whether
> there's an identical one in the queue".
>
> Likewise we could introduce a three-argument form of pg_notify(text, text,
> bool) where the final argument is whether you are interested in removing
> duplicates.
>
> 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?
>
> Cheers,
> BJ

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Recently added typedef "string" is a horrid idea
Next
From: Robert Haas
Date:
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)