Re: Optimize LISTEN/NOTIFY

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2025-10-28 06:46:50
Message-ID: 87E40BF8-8877-4DBD-9040-99AF8A4E6358@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 28, 2025, at 14:41, Joel Jacobson <joel(at)compiler(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message BharatDB 2025-10-28 07:13:35 Re: Make GiST waldump output more descriptive
Previous Message Joel Jacobson 2025-10-28 06:41:29 Re: Optimize LISTEN/NOTIFY