On Mon, Nov 3, 2025, at 12:02, Heikki Linnakangas wrote:
> I wrote another little stand-alone performance test program for this,
> attached. It launches N connections that send NOTIFYs to a single
> channel as fast as possible, and M threads that listen for the
> notifications. I ran it with different combinations of N and M, on
> 'master' and on REL_14_STABLE (which didn't have SLRU banks) and I
> cannot discern any performance difference from these patches. So it
> seems that holding the SLRU (bank) lock across the
> TransactionIdDidCommit() calls is fine.
Nice! That for the benchmark code! I took the liberty of hacking a bit
on it, and added support for multiple channels, with separate listener
and notifier threads per channel. Each notification now carries the
notifier ID, a sequence number, and a send timestamp. Listeners verify
that sequence numbers arrive in order and record delivery latency. The
program collects latency measurements into fixed buckets and reports
them once per second together with total and per-second send/receive
counts.
Also added a short delay before starting notifiers so that listeners
have time to issue their LISTEN commands, and a new --channels option,
and the meaning of --listeners and --notifiers was changed to apply per
channel.
Also fixed so the code could be compiled outside of the PostgreSQL
source code repo, if wanting to build this as stand-alone tool.
I've benchmarked master vs 0001+0002 and can't notice any differences;
see attached output from benchmark runs.
/Joel