Re: proposal: make NOTIFY list de-duplication optional
| От | Brendan Jurd |
|---|---|
| Тема | Re: proposal: make NOTIFY list de-duplication optional |
| Дата | |
| Msg-id | CADxJZo16qGNKhROpM-7hg6xgxNMarh2kBW=2suOCv+5EbPUfsw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: make NOTIFY list de-duplication optional (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: proposal: make NOTIFY list de-duplication optional
Re: proposal: make NOTIFY list de-duplication optional |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: