From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Chao Li" <li(dot)evan(dot)chao(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize LISTEN/NOTIFY |
Date: | 2025-10-16 18:16:25 |
Message-ID: | cbabbb45-ec27-47f1-a8f3-eb29073e9aef@app.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 16, 2025, at 04:54, Chao Li wrote:
>> On Oct 15, 2025, at 23:36, Joel Jacobson <joel(at)compiler(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-10-16 18:17:51 | Re: Making pg_rewind faster |
Previous Message | Tom Lane | 2025-10-16 18:12:47 | Re: Optimizing ResouceOwner to speed up COPY |