Re: [PATCH] Improve performance of NOTIFY over many databases (v2)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Improve performance of NOTIFY over many databases (v2)
Дата
Msg-id 22204.1568153938@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [PATCH] Improve performance of NOTIFY over many databases (v2)  (Martijn van Oosterhout <kleptog@gmail.com>)
Ответы Re: [PATCH] Improve performance of NOTIFY over many databases (v2)  (Martijn van Oosterhout <kleptog@gmail.com>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@gmail.com> writes:
> The original three patches have been collapsed into one as given the
> changes discussed it didn't make sense to keep them separate. There
> are now two patches (the third is just to help with testing):

> Patch 1: Tracks the listening backends in a list so non-listening
> backends can be quickly skipped over. This is separate because it's
> orthogonal to the rest of the changes and there are other ways to do
> this.

> Patch 2: This is the meat of the change. It implements all the
> suggestions discussed:

I pushed 0001 after doing some hacking on it --- it was sloppy about
datatypes, and about whether the invalid-entry value is 0 or -1,
and it was just wrong about keeping the list in backendid order.
(You can't conditionally skip looking for where to put the new
entry, if you want to maintain the order.  I thought about just
defining the list as unordered, which would simplify joining the
list initially, but that could get pretty cache-unfriendly when
there are lots of entries.)

0002 is now going to need a rebase, so please do that.

            regards, tom lane



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

Предыдущее
От: Nikita Glukhov
Дата:
Сообщение: Re: [PATCH] Opclass parameters
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Multivariate MCV list vs. statistics target