Re: proposal: make NOTIFY list de-duplication optional - Mailing list pgsql-hackers

From Filip Rembiałkowski
Subject Re: proposal: make NOTIFY list de-duplication optional
Date
Msg-id CAP_rwwkG5pkGLAXz4h9ax7Qy2oyJNyjJfw6iQyTJvdPTC0TSAA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: make NOTIFY list de-duplication optional  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: proposal: make NOTIFY list de-duplication optional
Re: proposal: make NOTIFY list de-duplication optional
List pgsql-hackers
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)

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: count_nulls(VARIADIC "any")
Next
From: Thomas Munro
Date:
Subject: Re: [ADMIN] 9.5 new setting "cluster name" and logging