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 1vfqse-005Uch-11 for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jan 2026 02:45:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfqsd-007gxo-1i for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Jan 2026 02:45:07 +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 1vfqsd-007gxg-0j for pgsql-hackers@lists.postgresql.org; Wed, 14 Jan 2026 02:45:07 +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 1vfqsX-000L6d-2q for pgsql-hackers@postgresql.org; Wed, 14 Jan 2026 02:45:07 +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 60E2ivsQ063379; Tue, 13 Jan 2026 21:44:57 -0500 From: Tom Lane To: "Joel Jacobson" cc: pgsql-hackers Subject: Re: Optimize LISTEN/NOTIFY In-reply-to: <903ce8c3-d991-4855-a5a1-ec39c64f713f@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-F22! F!C!3!4!29AE8@gmail.com> <1547585.1760645808@sss.pgh.pa.us> <14865EB6-0BF4-462B-9072-10BD Comments: In-reply-to "Joel Jacobson" message dated "Tue, 13 Jan 2026 13:10:20 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63377.1768358697.1@sss.pgh.pa.us> Date: Tue, 13 Jan 2026 21:44:57 -0500 Message-ID: <63378.1768358697@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I've been studying the v34 patch all day, and there is one change I don't think I agree with. It looks to me like the new logic in SignalBackends will have the effect of wakening any idle backend that is not up-to-the-moment. This seems like a pretty awful idea for use-cases where there are many backends that aren't interested in particular notifications. In particular it's totally discarding the previous concept of allowing idle backends in other databases to sleep for quite a long while. If we are able to do a direct advance, then great; but if we can't, I don't think that an immediate forced wakening is a good idea. That backend will already be stuck with reading through some data it doesn't care about, but I don't see how forcing it to do that work in small bites improves matters. We're trying to reduce the number of wakeups, not increase it. I think that if we have a backend that isn't interested in our notifications, and we can't direct-advance it, we should apply the same behavior that was previously used for backends in other databases. That was basically a conservative approximation to "isn't interested", and I don't see why it wouldn't work fine when we have a more accurate idea of "isn't interested". regards, tom lane