| От | 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
|
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера