On Sat, Feb 6, 2016 at 6:03 AM, Filip Rembiałkowski <filip.rembialkowski@xxxxxxxxx> wrote: > Thanks for the feedback. > > This patch is my first and obvious approach. > > @Merlin, I'm not sure if I get your idea: > - keep previous behaviour as obligatory? (which is: automatic > de-duplicating of incoming messages by channel+payload), > - instead of trivial search (sorting by browsing) use some kind of > faster lookups? > > I'm not sure if this statement in async.c is carved in stone: > > * Duplicate notifications from the same transaction are sent out as one > * notification only. This is done to save work when for example a trigger > * on a 2 million row table fires a notification for each row that has been > * changed. If the application needs to receive every single notification > * that has been sent, it can easily add some unique string into the extra > * payload parameter. > > 1) "work-saving" is disputable in some cases > > 2) an idea to "add some unique string" is OK logical-wise but it's not > OK performance-wise. > > Current search code is a sequential search: > https://github.com/filiprem/postgres/blob/master/src/backend/commands/async.c#L2139 > > I'm not that smart to devise an algorithm for faster lookups - > probably you guys can give some advice. > > Again, my rationale is... This feature can burn a lot of CPU for > nothing. I was hoping to use NOTIFY/LISTEN as superfast notification > mechanism. Superfast regardless on whether you insert 100, 10k or 1m > rows. Sure, I get it -- you want to have fast notification events -- this is a good thing to want to have. However, a GUC is probably not the best way to do that in this particular case. It's way to fringey and the bar for behavior controlling GUC is incredibly high (short version: most modern introductions were to manage security issues). I'm far from the last word on this thoug, but it's better to get this all sorted out now. Anyways, it should be possible to micro-optimize that path. Perhaps using a hash table? I'm not sure. Another possible way to work things out here is to expose your switch in the syntax of the command itself, or perhaps via the pg_notify function to avoid syntax issues. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
