Re: Timing overhead and Linux clock sources - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Timing overhead and Linux clock sources
Date
Msg-id 503C373C.1040704@2ndQuadrant.com
Whole thread Raw
In response to Re: Timing overhead and Linux clock sources  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Timing overhead and Linux clock sources
Re: Timing overhead and Linux clock sources
Re: Timing overhead and Linux clock sources
List pgsql-hackers
On 08/27/2012 06:20 PM, Bruce Momjian wrote:
> On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
>> I don't see why it's better for the first line to have a big number
>> than the last line.  What difference does it make?
>
> When you are looking at that output, the<1 usec is where you want to
> see most of the percentage, and it trails off after that.

After staring at all the examples I generated again, I think Bruce is 
right that the newer format he's suggesting is better.  I know I never 
thought about whether reordering for easier interpretation made sense 
before, and I'd also guess "it was less coding" for the existing order 
was the only reason Ants did it that way.

Where I think this is a most useful improvement is when comparing two 
systems with different results that don't end at the same boundary.  The 
proposed formatting would show the good vs. bad examples I put in the 
docs like this:
   < usec:      count   percent        1:   27694571 90.23734%        2:    2993204  9.75277%        4:       3010
0.00981%       8:         22  0.00007%       16:          1  0.00000%       32:          1  0.00000%
 
   < usec:      count   percent        1:    1155682 27.84870%        2:    2990371 72.05956%        4:       3241
0.07810%       8:        563  0.01357%       16:          3  0.00007%
 

And I think it's easier to compare those two in that order.  The docs do 
specifically suggest staring at the <1 usec numbers first, and having 
just mocked up both orders I do prefer this one for that job.  The way 
this was originally written, it's easier to come to an initially 
misleading conclusion.  The fact that the first system sometimes spikes 
to the 32 usec range is the first thing that jumps out at you in the 
originally committed ordering, and that's not where people should focus 
first.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Advisory Lock BIGINT Values
Next
From: Bruce Momjian
Date:
Subject: Re: Timing overhead and Linux clock sources