Re: proposal: make NOTIFY list de-duplication optional
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: Filip Rembiałkowski <filip.rembialkowski@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-06T17:50:59Z
Lists: pgsql-hackers
On 02/05/2016 08:49 PM, Tom Lane wrote: > Yeah, I agree that a GUC for this is quite unappetizing. Agreed. > > One idea would be to build a hashtable to aid with duplicate detection > (perhaps only once the pending-notify list gets long). > > Another thought is that it's already the case that duplicate detection is > something of a "best effort" activity; note for example the comment in > AsyncExistsPendingNotify pointing out that we don't collapse duplicates > across subtransactions. Would it be acceptable to relax the standards > a bit further? For example, if we only checked for duplicates among the > last N notification list entries (for N say around 100), we'd probably > cover just about all the useful cases, and the runtime would stay linear. > The data structure isn't tremendously conducive to that, but it could be > done. > > I like the hashtable idea if it can be made workable. cheers andrew
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