From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify rewrite |
Date: | 2009-11-13 13:33:46 |
Message-ID: | 20091113133346.GC4459@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joachim Wieland wrote:
> 1. Instead of placing the queue into shared memory only I propose to create a
> new subdirectory pg_notify/ and make the queue slru-based, such that we do not
> risk blocking. Several people here have pointed out that blocking is a true
> no-go for a new listen/notify implementation. With an slru-based queue we have
> so much space that blocking is really unlikely even in periods with extreme
> notify bursts.
> Regarding performance, the slru-queue is not fsync-ed to disk so most activity
> would be in the OS file cache memory anyway and most backends will probably
> work on the same pages most of the time. However more locking overhead is
> required in comparison to a shared-memory-only implementation.
Note, however, that pg_subtrans is also supposed to use "the same pages
from memory most of the time" and it still is a performance bottleneck
in some cases, and enlarging NUM_SUBTRANS_BUFFERS is a huge boon. I
think holding AsyncCtlLock in exclusive mode for every notify add (which
may involve I/O) is going to be a hard hit on scalability.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-11-13 13:34:53 | Re: next CommitFest |
Previous Message | Andrew Dunstan | 2009-11-13 13:32:33 | Re: CTE containing ambiguous columns |