Re: Optimize LISTEN/NOTIFY

On Tue, Oct 28, 2025, at 02:02, Chao Li wrote:
>>> From this perspective, we need to add a new field
>>> adviancingTillPos to QueueBackendStatus. (This field was also missing
>>> from my proposed patch).
>>
>> I'm doubtful yet another field is worth the added complexity cost.
>>
>> Before increasing the complexity further, I think we should first
>> try to simulate somewhat realistic workloads, to see if we actually
>> have a problem first.
>>
>> /Joel
>>
>
> I don’t think that’s extra complexity, IMO, that just ensure “direct
> advancement” to be fully functional.

An extra field is by definition extra complexity;
If it's worth it depends on how much we would gain from it,
that's why I'm doubtful it's worth it.

The extra adviancingTillPos field would only avoid wakeups in some
scenarios, if you study the example given by Arseniy, it's easy to see
why we would really need something like a the list of skip ranges
Arseniy suggested, per backend, for it to be complete,
but that's even more complexity.

I don't think it's too bad for a backend to read through the entire
queue, even if it contains some entires that are not interesting, when a
backend is awaken, processing is fast, that's not the big cost here,
what really costs is the context switches. But I've been wrong before,
so could be wrong again of course. This is just based on my intuition.

> But anyway, we should run some load tests to verify every solution to
> see how much they really improve. Do you already have or plan to work
> on a load test script?

Yes, I'm currently working on a combined benchmark / correctness test suite.

/Joel