Re: Lock Wait Statistics (next commitfest) - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: Lock Wait Statistics (next commitfest)
Date
Msg-id 4A7E1C96.3090201@paradise.net.nz
Whole thread Raw
In response to Re: Lock Wait Statistics (next commitfest)  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: Lock Wait Statistics (next commitfest)  (Stephen Frost <sfrost@snowman.net>)
Re: Lock Wait Statistics (next commitfest)  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List pgsql-hackers
Mark Kirkwood wrote:
> Mark Kirkwood wrote:
>> Jaime Casanova wrote:
>>> On Fri, Jul 17, 2009 at 3:38 AM, Mark
>>> Kirkwood<markir@paradise.net.nz> wrote:
>>>
>>>> With respect to the sum of wait times being not very granular, yes
>>>> - quite
>>>> true. I was thinking it is useful to be able to answer the question
>>>> 'where
>>>> is my wait time being spent' - but it hides cases like the one you
>>>> mention.
>>>> What would you like to see?  would max and min wait times be a useful
>>>> addition, or are you thinking along different lines?
>>>>
>>>>
>>>
>>> track number of locks, sum of wait times, max(wait time).
>>> but actually i started to think that the best is just make use of
>>> log_lock_waits send the logs to csvlog and analyze there...
>>>
>>>
>> Right - I'll look at adding max (at least) early next week.
>>
>>
>>
>>
> Patch with max(wait time).
>
> Still TODO
>
> - amalgamate individual transaction lock waits
> - redo (rather ugly) temporary pg_stat_lock_waits in a form more like
> pg_locks
>
This version has the individual transaction lock waits amalgamated.

Still TODO: redo pg_stat_lock_waits ...


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Split-up ECPG patches
Next
From: Bruce Momjian
Date:
Subject: Re: revised hstore patch