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.96) (envelope-from ) id 1vgFFu-009rWH-12 for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jan 2026 04:46:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vgFFt-00Ek9o-1k for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Jan 2026 04:46:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vgFFt-00Ek9g-0p for pgsql-hackers@lists.postgresql.org; Thu, 15 Jan 2026 04:46:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vgFFr-000YW3-1c for pgsql-hackers@postgresql.org; Thu, 15 Jan 2026 04:46:45 +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 60F4keQL527441; Wed, 14 Jan 2026 23:46:40 -0500 From: Tom Lane To: "Joel Jacobson" cc: pgsql-hackers Subject: Re: Optimize LISTEN/NOTIFY In-reply-to: <18521cfd-830e-4e8f-bcb0-eacee535480a@app.fastmail.com> 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-F! !22!F!C!3!4!29AE8@gmail.com> <1547585.1760645808@sss.pgh.pa.us> <14865EB6-0BF4-462B-9072- Comments: In-reply-to "Joel Jacobson" message dated "Thu, 15 Jan 2026 03:14:09 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <527439.1768452400.1@sss.pgh.pa.us> Date: Wed, 14 Jan 2026 23:46:40 -0500 Message-ID: <527440.1768452400@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, Jan 15, 2026, at 00:09, Tom Lane wrote: >> I spent some time trying to measure the impact of that point, >> by modifying the test program you posted upthread so that >> some notifiers go at full speed while others respond to the >> rate-limit switch so that they can be made to go slowly. >> I couldn't really see any difference between what you have in v34 >> and doing this the old way. > I reran the old benchmark [1] and got almost identical results as before > on my MacBook Pro M3 Max, when I tested v34 against patching v34 with > adding back the QUEUE_CLEANUP_DELAY logic: > ... > However, I completely failed to reproduce this difference on my Intel > and AMD machines! Fascinating. I was doing my testing on Intel (RHEL8). I'd bet a good deal that this is more about the OS than the hardware. I wonder if newer Linux versions behave differently. I can try to reproduce your results tomorrow on macOS (M4 Pro chip). > I have no idea what could explain the difference on my M3 Max. Not sure > if it's due to macOS or due to the aarch64 CPU. It's still much faster > than master, so I think this is fine, we can always come back to this in > the future, if there is evidence this is not just an edge-case. There's no question IMO that this patch is fundamentally a win. Maybe we can tweak it some more for edge cases, but I think in the main we should avoid changing edge-case behaviors that we don't have solid evidence about. > I therefore agree with your change of bringing back the "wake laggers" > logic, even though it could possibly cause a few listening backends to > receive their notifications a bit later than they otherwise would. Hm, I don't see how this would delay any notifications? Any sender that sent anything the laggard would be interested in should have woken it up. There might be a reason to worry about missed signals, though. With the addition of the QUEUE_BACKEND_WAKEUP_PENDING flag, nobody will ever re-signal a laggard backend, and maybe that would be a problem sometimes. I think the existing code is a bit more robust against that possibility, though it does rely on a continuing stream of notifiers. regards, tom lane