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
