On Mon, Jan 9, 2017 at 12:13 AM, Haribabu Kommi
wrote:
> Whenever the Backend is waiting for an LWLock, it sends the message to
> "stats collector" with PID and wait_event_info of the lock. Once the stats
> collector receives the message, Adds that Backend entry to Hash
[ Re sending to Hackers as the earlier mail failed to deliver to Hackers
mailing list]
On Mon, Jan 9, 2017 at 4:13 PM, Haribabu Kommi
wrote:
>
>
> On Thu, Aug 25, 2016 at 2:46 PM, Haribabu Kommi
> wrote:
>
>> On Thu, Aug 25, 2016 at 6:57 AM,
2016-08-25 13:46 GMT+09:00 Haribabu Kommi :
> On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
>> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
>> wrote:
>>>
>>> Based on the performance impact with the additional
On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
> wrote:
>>
>> Based on the performance impact with the additional timing calculations,
>> we can decide the view default behavior, Are there any
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi
> calculations may cause performance problem. Is there any need of writing
> this stats information to file? As this just provides the wait time
> information.
Yes, saving the
On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
wrote:
> There was some discussion earlier in adding pg_stat_lwlock view in [1].
> The main objections which I observed for that patch was showing LWLOCK
> information to the user that don't understand what this lock used
There was some discussion earlier in adding pg_stat_lwlock view in [1].
The main objections which I observed for that patch was showing LWLOCK
information to the user that don't understand what this lock used for and etc.
Currently as part of wait_event information in pg_stat_activity the LWLOCK