Re: Timing overhead and Linux clock sources

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Timing overhead and Linux clock sources
Дата
Msg-id 503C373C.1040704@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Timing overhead and Linux clock sources  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Timing overhead and Linux clock sources
Re: Timing overhead and Linux clock sources
Re: Timing overhead and Linux clock sources
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Advisory Lock BIGINT Values
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Timing overhead and Linux clock sources