Marko Tiikkaja <marko@joh.to> writes:
> I've in the past wanted to listen on all notification channels in the
> current database for debugging purposes. But recently I came across
> another use case. Since having multiple postgres backends listening for
> notifications is very inefficient (one Thursday I found out 30% of our
> CPU time was spent spinning on s_locks around the notification code), it
> makes sense to implement a notification server of sorts which then
> passes on notifications from postgres to interested clients.
... and then you gotta get the notifications to the clients, so it seems
like this just leaves the performance question hanging. Why don't we find
and fix the actual performance issue (assuming that 07e4d03fb wasn't it)?
The reason I'm not terribly enthused about this proposal is that some
implementations of LISTEN (for example, our pre-9.0 one) would be unable
to support LISTEN *. It's not too hard to imagine that at some point we
might wish to redo the existing implementation to reduce the overhead of
all listeners seeing all messages, and then having promised we could do
LISTEN * would be a serious restriction on our flexibility. So while
I'm not necessarily trying to veto the idea, I think it has significant
opportunity cost, and I'd like to see a more solid rationale than this
one before we commit to it.
In any case, it would be good to understand exactly what's the performance
issue that's biting you. Can you provide a test case that reproduces
that behavior?
regards, tom lane