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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Improve performance of NOTIFY over many databases (v2)
Дата
Msg-id 28365.1568640815@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [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:
> On Mon, 16 Sep 2019 at 00:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... I also think we
>> can simplify the handling of other-database listeners by including
>> them in the set signaled by SignalBackends, but only if they're
>> several pages behind.  So that leads me to the attached patch;
>> what do you think?

> I think I like the idea of having SignalBackend do the waking up a
> slow backend but I'm not enthused by the "lets wake up (at once)
> everyone that is behind". That's one of the issues I was explicitly
> trying to solve. If there are any significant number of "slow"
> backends then we get the "thundering herd" again.

But do we care?  With asyncQueueAdvanceTail gone from the listeners,
there's no longer an exclusive lock for them to contend on.  And,
again, I failed to see any significant contention even in HEAD as it
stands; so I'm unconvinced that you're solving a live problem.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: block-level incremental backup
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks