public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Joel Jacobson <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Thu, 16 Oct 2025 10:54:12 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>



> 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/

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Optimize LISTEN/NOTIFY
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox