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

Re: Timing overhead and Linux clock sources

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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:13:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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 

Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-08-28 03:16:28
Subject: Re: Timing overhead and Linux clock sources
Previous:From: Bruce MomjianDate: 2012-08-28 02:36:58
Subject: Re: Advisory Lock BIGINT Values

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