Idle idea for improving concurrency of LISTEN/NOTIFY
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
Added to TODO:
o Improve LISTEN concurrency
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01106.php
---------------------------------------------------------------------------
Tom Lane wrote:
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +