Re: Re[2]: LISTEN/NOTIFY ultra slow speed

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re[2]: LISTEN/NOTIFY ultra slow speed
Дата
Msg-id 317665.1647354727@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re[2]: LISTEN/NOTIFY ultra slow speed  (Арсен Арутюнян <arutar@bk.ru>)
Ответы Re[4]: LISTEN/NOTIFY ultra slow speed  (Арсен Арутюнян <arutar@bk.ru>)
Список pgsql-general
=?UTF-8?B?0JDRgNGB0LXQvSDQkNGA0YPRgtGO0L3Rj9C9?= <arutar@bk.ru> writes:
> i looked at the file "\src\backend\commands\async.c"
> there is a check for duplicate messages

Yup.

> Is this slowdown related to this check?

[ shrug... ]  You've provided no evidence either for or against that
possibility.

It seems a little unlikely that you could have a lot of pending messages
without also seeing data accumulating in pg_notify/, but on the other hand
it's also hard to think of other places that time could be getting spent
if the queue is always empty.  Can you use perf(1) or some such tool to
try to identify where the time is being spent?  There's some advice
about that here:

https://wiki.postgresql.org/wiki/Profiling_with_perf

> Is it possible to skip the check if I'm absolutely sure the message is unique?

Not a good idea.  You could upgrade to PG 13 or later, where that
code has been improved.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [External]Re: Postgres Crash Issue
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Restoring using PG_DUMP in PG12 results in