> On Oct 15, 2025, at 23:36, Joel Jacobson <[email protected]> wrote:
>
>> I agree with Tom that GetPendingNotifyChannels() is too heavy and
>> unnecessary.
>>
>> In PreCommit_Notify(), we can maintain a local hash table to record
>> pending nofications’ channel names. dahash also supports hash table in
>> local memory.
>
> I'm confused, I assume you mean "dynahash" since there is no "dahash"
> in the sources? I see dynahash has local-to-a-backend support,
> but I don't see why we would need a hash table for this,
> we just iterate over it once in SignalBackends,
> I think the local list is fine.
>
> 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.
In v18, I see you are building “pendingNotifyChannels” in PreCommit_Notify()
with “List”:
```
+ /*
+ * Build list of unique channels for SignalBackends().
+ */
+ pendingNotifyChannels = NIL;
+ foreach_ptr(Notification, n, pendingNotifies->events)
+ {
+ char *channel = n->data;
+
+ /* Add if not already in list */
+ if (!list_member_ptr(pendingNotifyChannels, channel))
+ pendingNotifyChannels =
lappend(pendingNotifyChannels, channel);
+ }
```
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
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
