| 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/
| 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 |