Re: proposal: LISTEN *

On 11/19/15 4:48 AM, Pavel Stehule wrote:
> 2015-11-19 4:40 GMT+01:00 Marko Tiikkaja <marko@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