Re: LISTEN / NOTIFY performance in 8.3

Tom Lane wrote:
> Hardly --- how's that going to pass a notify name?  Also, a lot of
> people want some payload data in a notify, not just a condition name;
> any reimplementation that doesn't address that desire probably won't
> get accepted.
>
Ah - forgot about the name.  At least there need be just one instance of
a name record queued
per worker if I'm reading the documentation right - it suggest that
notifications can be folded
with the proviso that if the process generates a notification and at
least one other process
generates a notification then it will get at least (but possibly only)
two events.  Not sure why
the PID is there rather than a couple of flag bits.

You'll alsways have the danger of overflowing a shm area and need to
spill: is the signal and then
lookup in storage materially quicker than using the master process to
route messages via pipes?
As you say, you have a lock contention issue and often the total signal
data volume outstanding
for a single back end will be less than will fit in a kernel's pipe buffer.

The sending processes can track what signals they've generated in the
current transaction so
the master (or signal distributor) needn't get bombarded with signals
from lots of rows within
one transaction.