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

Re: Timing overhead and Linux clock sources

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timing overhead and Linux clock sources
Date: 2012-08-28 03:16:28
Message-ID: 20120828031628.GA16116@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Aug 27, 2012 at 11:13:00PM -0400, Greg Smith wrote:
> 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.

Yes, I was totally confused how you would explain how to analyze this. 
Once the patch is applied you might find it easier to clearly state
that in the docs.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2012-08-28 03:21:38
Subject: Minor comment fixups
Previous:From: Greg SmithDate: 2012-08-28 03:13:00
Subject: Re: Timing overhead and Linux clock sources

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