Horton

Re: Optimize LISTEN/NOTIFY

Joel Jacobson <joel@compiler.org>

View thread
From: "Joel Jacobson" <joel@compiler.org>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-15T21:50:42Z
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

Attachments

On Tue, Jul 15, 2025, at 22:56, Joel Jacobson wrote:
> On Tue, Jul 15, 2025, at 09:20, Joel Jacobson wrote:
>> On Sun, Jul 13, 2025, at 01:18, Tom Lane wrote:
>>> "Joel Jacobson" <joel@compiler.org> writes:
>>>> The attached proof-of-concept patch proposes a straightforward
>>>> optimization for the single-listener case. It introduces a shared-memory
>>>> hash table mapping (dboid, channelname) to the ProcNumber of a single
>>>> listener.
>>>
>>> What does that do to the cost and parallelizability of LISTEN/UNLISTEN?
>>
>> Good point. The previous patch would effectively force all LISTEN/UNLISTEN
>> to be serialized, which would at least hurt parallelizability.
>>
>> New benchmark confirm this hypothesis.
>>
>> New patch attached that combines two complementary approaches, that together
>> seems to scale well for both common-channel and unique-channel scenarios:
>
> Thanks to the FreeBSD animal failing, I see I made a shared memory blunder.
> New squashed patch attached.
>
> /Joel
> Attachments:
> * 0001-Subject-Optimize-LISTEN-NOTIFY-signaling-for-scalabi-v3.patch

(cfbot is not picking up my patch; I wonder if some filename length is exceeded,
trying a shorter filename, apologies for spamming)

/Joel