Horton

Re: Optimize LISTEN/NOTIFY

Joel Jacobson <joel@compiler.org>

View thread
From: "Joel Jacobson" <joel@compiler.org>
To: "Chao Li" <li.evan.chao@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-16T18:16:25Z
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 Thu, Oct 16, 2025, at 04:54, Chao Li wrote:
>> On Oct 15, 2025, at 23:36, Joel Jacobson <joel@compiler.org> wrote:
>> The latest version gets rid of GetPendingNotifyChannels()
>> and replaces it with the local list pendingNotifyChannels.
>
> Sorry for the typo, Yes, I meant to dynahash” that you have already 
> been using it.
...
> My suggestion of using dynahah was for the same purpose. Because 
> list_member_ptr() iterates through all list nodes until find the 
> target, so this code is still O(n^2).
>
> Using a hash will make it faster. I used to work on project Concourse 
> [1]. The system is heavily using the LISTEN/NOTIFY mechanism. There 
> would be thousands of channels at runtime. In that case, hash search 
> would be much faster than linear search.
>
> [1] https://github.com/concourse/concourse

Building pendingNotifyChannels is O(N^2) yes, but how large N is
realistic here?

Note that pendingNotifyChannels is only the unique channels for the
notifications in the *current transaction*. At Concourse, did you really
do thousands of NOTIFY, with unique channel names, within the same
transaction?

/Joel