Re: proposal: make NOTIFY list de-duplication optional
От | Vik Fearing |
---|---|
Тема | Re: proposal: make NOTIFY list de-duplication optional |
Дата | |
Msg-id | 56B7224C.4090807@2ndquadrant.fr обсуждение исходный текст |
Ответ на | Re: proposal: make NOTIFY list de-duplication optional (Filip Rembiałkowski <filip.rembialkowski@gmail.com>) |
Ответы |
Re: proposal: make NOTIFY list de-duplication optional
|
Список | pgsql-hackers |
On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > +1 > > ... and a patch (only adding ALL keyword, no hash table implemented yet). Please stop top-posting, it's very disruptive. My comments are below, where they belong. > 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? On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > +1 > > ... and a patch (only adding ALL keyword, no hash table implemented yet). I only read through the patch, I didn't compile it or test it, but I have a few comments: You left the duplicate behavior with subtransactions, but didn't mention it in the documentation. If I do NOTIFY DISTINCT chan, 'msg'; then I expect only distinct notifications but I'll get duplicates if I'm in a subtransaction. Either the documentation or the code needs to be fixed. I seem to remember some discussion about not using DEFAULT parameters in system functions so you should leave the old function alone and create a new function with your use_all parameter. I don't recall the exact reason why so hopefully someone else will enlighten me. There is also no mention in the documentation about what happens if I do: NOTIFY ALL chan, 'msg'; NOTIFY ALL chan, 'msg'; NOTIFY DISTINCT chan, 'msg'; NOTIFY ALL chan, 'msg'; Without testing, I'd say I'd get two messages, but it should be explicitly mentioned somewhere. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: