Re: proposal: make NOTIFY list de-duplication optional

Поиск
Список
Период
Сортировка
От Filip Rembiałkowski
Тема Re: proposal: make NOTIFY list de-duplication optional
Дата
Msg-id CAP_rwwkG5pkGLAXz4h9ax7Qy2oyJNyjJfw6iQyTJvdPTC0TSAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: make NOTIFY list de-duplication optional  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: proposal: make NOTIFY list de-duplication optional  (Vik Fearing <vik@2ndquadrant.fr>)
Re: proposal: make NOTIFY list de-duplication optional  (Merlin Moncure <mmoncure@gmail.com>)
Список 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)

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: count_nulls(VARIADIC "any")
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [ADMIN] 9.5 new setting "cluster name" and logging