Skip site navigation (1) Skip section navigation (2)

Re: Timing overhead and Linux clock sources

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(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-27 17:29:18
Message-ID: 20120827172918.GQ11088@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-08-27 17:40:40
Subject: Re: temporal support patch
Previous:From: Robert HaasDate: 2012-08-27 17:28:09
Subject: Re: spinlocks on HP-UX

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group