Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Chao Li
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id 87E40BF8-8877-4DBD-9040-99AF8A4E6358@gmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: Optimize LISTEN/NOTIFY
List pgsql-hackers

> On Oct 28, 2025, at 14:41, Joel Jacobson <joel@compiler.org> wrote:
>
> 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.
>

Cool. Then we can run the benchmark and decide.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize LISTEN/NOTIFY
Next
From: BharatDB
Date:
Subject: Re: Make GiST waldump output more descriptive