Re: proposal: make NOTIFY list de-duplication optional

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: make NOTIFY list de-duplication optional
Дата
Msg-id 7647.1454723392@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: make NOTIFY list de-duplication optional  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: proposal: make NOTIFY list de-duplication optional  (Brendan Jurd <direvus@gmail.com>)
Re: proposal: make NOTIFY list de-duplication optional  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 5, 2016 at 10:17 AM, Filip Rembiałkowski
> <filip.rembialkowski@gmail.com> wrote:
>> - new GUC in "Statement Behaviour" section, notify_duplicate_removal

> 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.

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.
        regards, tom lane



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

Предыдущее
От: Paul Jungwirth
Дата:
Сообщение: Re: Review: GiST support for UUIDs
Следующее
От: Tom Lane
Дата:
Сообщение: Explanation for bug #13908: hash joins are badly broken