Re: proposal: make NOTIFY list de-duplication optional
От | Filip Rembiałkowski |
---|---|
Тема | Re: proposal: make NOTIFY list de-duplication optional |
Дата | |
Msg-id | CAP_rww=xRoBfbAqkywCHTs3jDxF9zknh1zLkrJKxZGykRtEHQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: make NOTIFY list de-duplication optional (Brendan Jurd <direvus@gmail.com>) |
Ответы |
Re: proposal: make NOTIFY list de-duplication optional
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: