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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers