Horton

Re: Optimize LISTEN/NOTIFY

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Joel Jacobson <joel@compiler.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-28T01:02:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Optimize LISTEN/NOTIFY via shared channel map and direct advancement.

  2. Fix incorrect logic for caching ResultRelInfos for triggers


> On Oct 27, 2025, at 14:18, Joel Jacobson <joel@compiler.org> wrote:
> 
> On Mon, Oct 27, 2025, at 02:27, Chao Li wrote:
>>> On Oct 27, 2025, at 07:24, Joel Jacobson <joel@compiler.org> wrote:
>>> 
>>> Write-up of changes since v20:
>>> 
>>> Two new fields have been added to QueueBackendStatus:
>>> + QueuePosition advisoryPos; /* safe skip-ahead position */
>>> + bool advancingPos; /* backend is reading the queue */
> ...
>> I did a quick review on v21 only focusing on the “direct advancement” logic.
>> 
>> In v21, you added advisoryPos and advancingPos which is same as my 
>> proposed solution. But you missed an important point from mine.
>> 
> ...
>> 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.

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?

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