Re: Idle idea for improving concurrency of LISTEN/NOTIFY - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Idle idea for improving concurrency of LISTEN/NOTIFY
Date
Msg-id 200804151509.m3FF9A306390@momjian.us
Whole thread Raw
In response to Idle idea for improving concurrency of LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] Avahi support for Postgresql
Next
From: Andrew Chernow
Date:
Subject: Re: pulling libpqtypes from queue