Date: Mon, 28 May 2007 22:21:54 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-patches@postgresql.org
Subject: Re: Logging checkpoints and other slowdown causes
In-Reply-To: <465B3ABB.6010709@enterprisedb.com>
Message-ID: <Pine.GSO.4.64.0705282200190.28443@westnet.com>
References: <Pine.GSO.4.64.0704010051050.14920@westnet.com>
	<200704030814.33999.peter_e@gmx.net>
	<Pine.GSO.4.64.0704030927180.5732@westnet.com>
	<46443F02.6060300@enterprisedb.com>
	<Pine.GSO.4.64.0705111009080.18685@westnet.com>
	<465B3ABB.6010709@enterprisedb.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

I'll take another stab at refining this can of worms I opened.  The one 
thing I noticed on a quick review is that it's almost possible to skip all 
the calls to gettimeofday if log_checkpoints is off now.  I'd like to make 
that a specific goal, because that will make me feel better that adding 
this code has almost no performance impact relative to now unless you turn 
the feature on.

I agree with Simon that tracking create/drop separately is unnecessary. 
As for why all the timing info is in ms, given the scale of the numbers 
typically encountered I found it easier to work with.  I originally wanted 
resolution down to 0.1ms if the underlying OS supports it, which means 4 
figures to the right of the decimal point if the unit was switched to 
seconds.  Quite often the times reported are less than 100ms, so you'll 
normally be dealing with fractional part of a second.  If we take Heikki's 
example:

LOG:  checkpoint complete; buffers written=3.1 MB (9.6%) write=96.8 ms 
sync=32.0 ms

And switch it to seconds:

LOG:  checkpoint complete; buffers written=3.1 MB (9.6%) write=0.0968 ms 
sync=0.0320 ms

I don't find that as easy to work with.  The only way a timing in seconds 
would look OK is if the resolution of the whole thing is reduced to ms, 
which then makes 3 decimal points--easy to read as ms instead.  Having 
stared at a fair amount of this data now, that's probably fine; I'll 
collect up some more data on it from a fast server this week to confirm 
whether's it's worthless precision or worth capturing.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD