Обсуждение: 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. +