Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v9UPA-001Kri-Nm for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Oct 2025 20:16:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v9UP9-00FLfG-MU for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Oct 2025 20:16:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v9UP9-00FLf3-DJ for pgsql-hackers@lists.postgresql.org; Thu, 16 Oct 2025 20:16:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v9UP6-0029q6-15 for pgsql-hackers@postgresql.org; Thu, 16 Oct 2025 20:16:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 59GKGmBT1547586; Thu, 16 Oct 2025 16:16:48 -0400 From: Tom Lane To: "Joel Jacobson" cc: "Chao Li" , pgsql-hackers Subject: Re: Optimize LISTEN/NOTIFY In-reply-to: References: <6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com> <165530.1752362320@sss.pgh.pa.us> <02a7cd37-e2fc-4212-8b19-f8c239c95fb8@app.fastmail.com> <96f00bf1-cc9d-4520-9d02-9e14e7767c88@app.fastmail.com> <30c2aa7d-dd6c-4b68-a2e4-f217a1a34acf@app.fastmail.com> <0b4d402a-9ac2-4aa8-acf8-8231dbe579ea@app.fastmail.com> <3095599.1758644879@sss.pgh.pa.us> <0dc6a2cc-5216-4dc1-9dd2-430cafc6095b@app.fastmail.com> <52CC167F-763B-4ECA-B0B4-DAB381816828@gmail.com> <9186C6D0-F7A9-482A-9183-89E530B57E36@gmail.com> <1073593.1759423179@sss.pgh.pa.us> <4bd5e6c4-6fa7-44bb-869d-59a32a331fa8@app.fastmail.com> <85828f29-e72e-4400-94f3-9a69bc8dc239@app.fastmail.com> <2495353.1759860890@sss.pgh.pa.us> <8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com> <2531672.1759868124@sss.pgh.pa.us> <474efa78-337c-41cd-a73a-f845a0115109@app.fastmail.com> <2749343.1759949176@sss.pgh.pa.us> <8bfca2be-1ec0-4e15-aafb-0b7b661fe936@app.fastmail.com> <9eba307f-f2fb-48f0-9507-2e197f39ef9e@app.fastmail.com> <8c71183a-0d28-4bcf-a806-78446ff95404@app.fastmail.com> <1009807.1760476747@sss.pgh.pa.us> <1F7227F5-C33D-4E2C-8511-33F1468590D0@gmail.com> <0a5a20d3-4621-46b3-b2ab-903f63a20dea@app.fastmail.com> <6F913129-ABEF-4004-AAF3-F22FC34! 29AE8@gmail.com> Comments: In-reply-to "Joel Jacobson" message dated "Thu, 16 Oct 2025 22:06:29 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1547584.1760645808.1@sss.pgh.pa.us> Date: Thu, 16 Oct 2025 16:16:48 -0400 Message-ID: <1547585.1760645808@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Joel Jacobson" writes: > On Thu, Oct 16, 2025, at 20:16, Joel Jacobson wrote: >> Building pendingNotifyChannels is O(N^2) yes, but how large N is >> realistic here? > I agree this looks like a real problem, since I guess it's not > completely unthinkable someone might have > some kind of trigger on a table, that could fire off NOTIFY > for each row, possibly causing hundreds of thousands of > notifies in the same db txn. We already de-duplicate identical NOTIFY operations for exactly that reason (cf. AsyncExistsPendingNotify). However, non-identical NOTIFYs obviously can't be merged. I wonder whether we could adapt that de-duplication logic so that it produces a list of unique channel names in addition to a list of unique NOTIFY events. One way could be a list/hashtable of channels used, and for each one a list/hashtable of unique payloads, rather than the existing single-level list/hashtable. regards, tom lane