On Mon, Aug 27, 2012 at 01:18:51PM -0400, Bruce Momjian wrote: > > > This should make the output clearer to eyeball for problems --- a good > > > timing has a high percentage on the first line, rather than on the last > > > line. > > > > I guess I'm not sure the output format is an improvement. I wouldn't > > care much one way or the other if we had made this change at the time > > in AS92, but I'm not sure it's really worth breaking compatibility for > > a format that may or may not be any better. The person who wrote the > > original code presumably preferred it way it already is. > > He wrote it that way to allow for simpler C code --- he could just start > from 31 and keeping skipping entries until he hit a non-zero. > > My format makes it easy to see which line should have the majority of > the entries, e.g. first line should be > 90%. I doubt there are enough > people running this cross-version that consistency in output makes any > difference between major PG versions.
The real weird part is that this tool outputs a variable number of rows/buckets, depending on the hightest non-zero bucket, so I had trouble understanding it when the last line was the one to look at, especially for multiple runs. Also, we heavily adjusted the output of pg_test_fsync for several major releases and that wasn't a problem for anyone. -- 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
