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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2012-08-28 03:21:38 | Minor comment fixups |
Previous Message | Greg Smith | 2012-08-28 03:13:00 | Re: Timing overhead and Linux clock sources |