On 11/19/15 4:48 AM, Pavel Stehule wrote:
2015-11-19 4:40 GMT+01:00 Marko Tiikkaja <ma...@joh.to>:
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. A server like this
would be a lot more simple to implement if there was a way to announce that
the client wants to see all notifications, regardless of the name of the
channel.
Attached is a very crude proof-of-concept patch implementing this. Any
thoughts on the idea?
It is looking much more like workaround. Proposed feature isn't bad, but
optimization of current implementation should be better.
Isn't possible to fix internal implementation?
It's probably possible to improve the internal implementation. But the
way I see it, it's always going to be less efficient than a dedicated
process outside the system (or maybe as a background worker?) handing
out notifications, so I don't see any point in spending my time on that.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
