Horton
Menu

Re: proposal: make NOTIFY list de-duplication optional

Filip Rembiałkowski <filip.rembialkowski@gmail.com>

View thread
From: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Vik Fearing <vik@2ndquadrant.fr>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-08T20:33:43Z
Lists: pgsql-hackers

Attachments

On Mon, Feb 8, 2016 at 1:52 PM, Craig Ringer <craig@2ndquadrant.com> wrote:

> Would it be correct to say that if ALL is specified then a message is queued
> no matter what. If DISTINCT is specified then it is only queued if no
> message with the same channel and argument is already queued for delivery.
Yes, exactly.

> Using DISTINCT can never decrease the total number of messages to be sent.
This sentence does not sound true. DISTINCT is the default, old
behaviour. It *can* decrease total number of messages (by
deduplication)

> I've found the deduplication functionality of NOTIFY very frustrating in the past
> and I see this as a significant improvement. Sometimes the *number of times*
> something happened is significant too...
yep, same idea here.




Here is my next try, after suggestions from -perf and -hackers list:

* no GUC

* small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT

* corresponding, 3-argument version of pg_notify(text,text,bool)

* updated the docs to include new syntax and clarify behavior

* no hashtable in AsyncExistsPendingNotify
 (I don't see much sense in that part; and it can be well done
separately from this)

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use a hash table to de-duplicate NOTIFY events faster.