public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joel Jacobson <[email protected]>
To: Chao Li <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Tue, 28 Oct 2025 07:41:29 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
	<[email protected]>
	<CAE7r3MK-3AOdh1mpZ8hw9h6F_i0D5RMoAy7CttnfCJRpB8GJDA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Optimize LISTEN/NOTIFY
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox