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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
