Re: LISTEN / NOTIFY performance in 8.3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: LISTEN / NOTIFY performance in 8.3
Дата
Msg-id 9501.1204066918@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: LISTEN / NOTIFY performance in 8.3  (Joel Stevenson <joelstevenson@mac.com>)
Ответы Re: LISTEN / NOTIFY performance in 8.3  (Joel Stevenson <joelstevenson@mac.com>)
Список pgsql-performance
Joel Stevenson <joelstevenson@mac.com> writes:
> What's really baffling is that there are plenty of other OLTP queries
> going in multiple backends simultaneously that don't fall over my
> 300ms query log threshold, and yet NOTIFY and LISTEN consistently do.
> What's more it's looks like it's only happening for registered
> listener relnames.

Hmm, that says that it's not a matter of locking on pg_listener,
but of actually applying the row update(s) and/or signaling the
recipient(s).  If you're not seeing performance issues for ordinary
table-update operations it's hard to see why pg_listener updates would
be any worse, so that seems to point the finger at the signaling.
Which is just a matter of a kill(2) and shouldn't be that expensive.

It might be interesting to try strace'ing the whole PG process tree
while these notifies are going on, and seeing if you can identify
any specific kernel calls that seem to take a long time.

            regards, tom lane

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

Предыдущее
От: James Mansion
Дата:
Сообщение: Re: LISTEN / NOTIFY performance in 8.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LISTEN / NOTIFY performance in 8.3