Skip site navigation (1) Skip section navigation (2)

Re: Lock Wait Statistics (next commitfest)

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lock Wait Statistics (next commitfest)
Date: 2009-07-25 00:29:01
Message-ID: 4A6A51CD.50604@paradise.net.nz (view raw or flat)
Thread:
Lists: pgsql-hackers
Mark Kirkwood wrote:
> Jaime Casanova wrote:
>> On Fri, Jul 17, 2009 at 3:38 AM, Mark 
>> Kirkwood<markir(at)paradise(dot)net(dot)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.
>

I'm also thinking of taking a look at amalgamating transaction type lock 
waits. This seems like a good idea because:

 - individually, and viewed at a later date, I don't think they 
individual detail is going to be useful
 - there will be a lot of them
 - I think the statistical data (count, sum elapsed, max elapsed) may be 
sufficiently interesting

Cheers

Mark

In response to

pgsql-hackers by date

Next:From: Sam MasonDate: 2009-07-25 00:30:07
Subject: Re: SE-PostgreSQL Specifications
Previous:From: Dave PageDate: 2009-07-25 00:24:28
Subject: Re: Proposal: More portable way to support 64bit platforms

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group