Re: Optimize LISTEN/NOTIFY

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