Re: proposal: make NOTIFY list de-duplication optional

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Re: proposal: make NOTIFY list de-duplication optional
Дата
Msg-id CADxJZo16qGNKhROpM-7hg6xgxNMarh2kBW=2suOCv+5EbPUfsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: make NOTIFY list de-duplication optional  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: make NOTIFY list de-duplication optional  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: proposal: make NOTIFY list de-duplication optional  (Filip Rembiałkowski <filip.rembialkowski@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Sat, 6 Feb 2016 at 12:50 Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> I agree with what Merlin said about this:
> http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yC10AHU1nFiA1tbHsg+35Ds-oEueUapo7t4g@mail.gmail.com

Yeah, I agree that a GUC for this is quite unappetizing.

How would you feel about a variant for calling NOTIFY?

The SQL syntax could be something like "NOTIFY [ALL] channel, payload" where the ALL means "just send the notification already, nobody cares whether there's an identical one in the queue".

Likewise we could introduce a three-argument form of pg_notify(text, text, bool) where the final argument is whether you are interested in removing duplicates.

Optimising the remove-duplicates path is still probably a worthwhile endeavour, but if the user really doesn't care at all about duplication, it seems silly to force them to pay any performance price for a behaviour they didn't want, no?

Cheers,
BJ

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: silent data loss with ext4 / all current versions