Idle idea for improving concurrency of LISTEN/NOTIFY

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Idle idea for improving concurrency of LISTEN/NOTIFY
Дата
Msg-id 5215.1204048454@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Idle idea for improving concurrency of LISTEN/NOTIFY  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Sooner or later we ought to completely reimplement LISTEN/NOTIFY,
but while thinking about Joel Stevenson's performance issue I had a
sudden idea for a very simple change that would buy some improvement.
Currently, all operations in async.c take ExclusiveLock on pg_listener,
but it strikes me that that is overkill.  Wouldn't it work fine to
take a plain writer's lock (ie, RowExclusiveLock) for operations that
are touching only the current backend's pg_listener entries?  We would
only need ExclusiveLock when we want to scribble on *other* backends'
entries, ie, only in AtCommit_Notify().  What this would mean is that
when a NOTIFY awakens multiple listeners, the listeners don't serialize
on the pg_listener lock in order to find and clear their table entries.
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Don't build the win32 support files in the all target, only in
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump additional options for performance