Re: Optimize LISTEN/NOTIFY

"Joel Jacobson" <joel@compiler.org> writes:
> On Thu, Jan 15, 2026, at 00:09, Tom Lane wrote:
>> I spent some time trying to measure the impact of that point,
>> by modifying the test program you posted upthread so that
>> some notifiers go at full speed while others respond to the
>> rate-limit switch so that they can be made to go slowly.
>> I couldn't really see any difference between what you have in v34
>> and doing this the old way.

> I reran the old benchmark [1] and got almost identical results as before
> on my MacBook Pro M3 Max, when I tested v34 against patching v34 with
> adding back the QUEUE_CLEANUP_DELAY logic:
> ...
> However, I completely failed to reproduce this difference on my Intel
> and AMD machines!

Fascinating.  I was doing my testing on Intel (RHEL8).  I'd bet a good
deal that this is more about the OS than the hardware.  I wonder if
newer Linux versions behave differently.

I can try to reproduce your results tomorrow on macOS (M4 Pro chip).

> I have no idea what could explain the difference on my M3 Max. Not sure
> if it's due to macOS or due to the aarch64 CPU. It's still much faster
> than master, so I think this is fine, we can always come back to this in
> the future, if there is evidence this is not just an edge-case.

There's no question IMO that this patch is fundamentally a win.
Maybe we can tweak it some more for edge cases, but I think in the
main we should avoid changing edge-case behaviors that we don't have
solid evidence about.

> I therefore agree with your change of bringing back the "wake laggers"
> logic, even though it could possibly cause a few listening backends to
> receive their notifications a bit later than they otherwise would.

Hm, I don't see how this would delay any notifications?  Any sender
that sent anything the laggard would be interested in should have
woken it up.

There might be a reason to worry about missed signals, though.
With the addition of the QUEUE_BACKEND_WAKEUP_PENDING flag,
nobody will ever re-signal a laggard backend, and maybe that
would be a problem sometimes.  I think the existing code is a
bit more robust against that possibility, though it does rely
on a continuing stream of notifiers.

			regards, tom lane