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% asyncQueueReadAllNotification
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 is left hanging
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% SIGetDat
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 client is connecte
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
notifications is very i
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 (one Thursday I fo
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 backends listening for
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
> notifications is very i
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 ti
