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.