Re: proposal: make NOTIFY list de-duplication optional
Filip Rembiałkowski <filip.rembialkowski@gmail.com>
From: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
To: Brendan Jurd <direvus@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-07T02:42:59Z
Lists: pgsql-hackers
Attachments
- postgres-notify-all.patch (text/x-patch) patch
+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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use a hash table to de-duplicate NOTIFY events faster.
- bb5ae8f6c416 13.0 landed