public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Joel Jacobson <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Tue, 13 Jan 2026 21:44:57 -0500
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]>
	<da0996! [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]>
	<6F913129-ABEF-4004-AAF3-F22! [email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>

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

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