public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joel Jacobson <[email protected]>
To: pgsql-hackers <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Tue, 13 Jan 2026 13:10:20 +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>
	<14865EB6-0BF4-462B-9072-10BDAC>
	<[email protected]>
	<[email protected]>

On Tue, Jan 13, 2026, at 06:46, Joel Jacobson wrote:
> On Wed, Jan 7, 2026, at 21:29, Tom Lane wrote:
>> That seems a little weird: surely such usage is not something we need
>> to optimize.  Maybe it can be justified because it makes the code
>> simpler, but that's not immediately obvious to me.
>
> The reason for not sticking to the two-boolean approach (staged/current)
> like in v32 was to minimize shared dshash operations in favor of local
> hash table operations.
...
> UNLISTEN during PreCommit doesn't touch the shared dshash at all, it
> just records the intent locally.  LISTEN pre-allocates once per channel.
> At commit we iterate the de-duplicated hash table, so we do one dshash
> operation per unique channel rather than per action.  That's 2 dshash
> operations in total.
>
> Since dshash operations involve shared memory access and potential
> contention, doing more work locally with a cheap hash table seemed like
> the right trade-off to me.

Correction to the above claims.
The per-action dshash reduction only applies to UNLISTEN, not LISTEN:

UNLISTEN: reduced from 2 to 1 dshash operation
  * v32: PreCommit dshash (set staged), AtCommit dshash (remove)
  * v34: PreCommit local hash only, AtCommit dshash (remove)

LISTEN: still 2 dshash operations (unchanged)
  * v32: PreCommit dshash (set staged), AtCommit dshash (set current)
  * v34: PreCommit dshash (find_or_insert), AtCommit dshash (set listening=true)

For LISTEN, the local hash table provides deduplication, not per-action
reduction.

For the admittedly silly `LISTEN foo; UNLISTEN foo; LISTEN foo;`
example, v34 does 3 dshash operations (not 2 as I stated): two
find_or_insert during PreCommit plus one find AtCommit.  Still better
than v32's 6.  I agree this isn't something we need to optimize for, but
it's a bonus we get for free thanks to the local hash table.

/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