Re: Optimize LISTEN/NOTIFY
| От | Joel Jacobson |
|---|---|
| Тема | Re: Optimize LISTEN/NOTIFY |
| Дата | |
| Msg-id | cbabbb45-ec27-47f1-a8f3-eb29073e9aef@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Optimize LISTEN/NOTIFY (Chao Li <li.evan.chao@gmail.com>) |
| Ответы |
Re: Optimize LISTEN/NOTIFY
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: