Idle idea for improving concurrency of LISTEN/NOTIFY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Idle idea for improving concurrency of LISTEN/NOTIFY
Date: 2008-02-26 17:54:14
Message-ID: 5215.1204048454@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-26 18:02:17 Re: pg_dump additional options for performance
Previous Message Peter Eisentraut 2008-02-26 17:43:42 Re: [COMMITTERS] pgsql: Don't build the win32 support files in the all target, only in