Re: [HACKERS] proposal: LISTEN *

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

Re: [HACKERS] proposal: LISTEN *

Alvaro Herrera writes: > Marko Tiikkaja wrote: >> On the test server I'm running on, it doesn't look quite as bad as the >> profiles we had in production, but s_lock is still the worst offender in the >> profiles, called from: >> >> - 80.33% LWLockAcquire >> + 48.34%

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja 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

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja writes: > On 11/19/15 4:21 PM, Tom Lane wrote: >> ... and then you gotta get the notifications to the clients, so it seems >> like this just leaves the performance question hanging. > I'm not sure which performance question you think is left hanging. If > every

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja wrote: > On the test server I'm running on, it doesn't look quite as bad as the > profiles we had in production, but s_lock is still the worst offender in the > profiles, called from: > > - 80.33% LWLockAcquire > + 48.34% asyncQueueReadAllNotifications > + 23.09%

Re: [HACKERS] proposal: LISTEN *

On 11/19/15 4:21 PM, Tom Lane wrote: Marko Tiikkaja 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

Re: [HACKERS] proposal: LISTEN *

On 11/19/15 5:32 PM, Tom Lane wrote: Marko Tiikkaja writes: On 11/19/15 4:21 PM, Tom Lane wrote: ... and then you gotta get the notifications to the clients, so it seems like this just leaves the performance question hanging. I'm not sure which performance question you think

Re: [HACKERS] proposal: LISTEN *

Hi 2015-11-19 4:40 GMT+01:00 Marko Tiikkaja : > 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 >