Re: Timing overhead and Linux clock sources

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com