Re: proposal: LISTEN *

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: LISTEN *
Дата
Msg-id CAFj8pRB=dx-CFht8X2yTOZ8ZpjuiNbNB66SoaPi_WN8zqqFxtw@mail.gmail.com
обсуждение исходный текст
Ответ на proposal: LISTEN *  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: proposal: LISTEN *
Список pgsql-hackers
Hi

2015-11-19 4:40 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
Hi,

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?

Pavel
 


.m


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual