From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Idle idea for improving concurrency of LISTEN/NOTIFY |
Date: | 2008-04-15 15:09:10 |
Message-ID: | 200804151509.m3FF9A306390@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2008-04-15 15:24:43 | Re: pulling libpqtypes from queue |
Previous Message | Alvaro Herrera | 2008-04-15 15:06:23 | Re: [PATCHES] Avahi support for Postgresql |