Date: Fri, 13 Jul 2007 08:08:13 -0400
From: Ray Stell <stellr@cns.vt.edu>
To: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL publishes first real benchmark
Message-ID: <20070713120813.GC5611@cns.vt.edu>
References: <46925AD9.9020208@sun.com> <4694FE64.8070407@enterprisedb.com>
	<4695063D.9040108@sun.com> <27436.1184173639@sss.pgh.pa.us>
	<469522A5.1070409@sun.com> <4695EF96.3060009@kaltenbrunner.cc>
	<87fy3tnbnn.fsf@oxford.xeocode.com>
	<Pine.GSO.4.64.0707121038120.21795@westnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.64.0707121038120.21795@westnet.com>
User-Agent: Mutt/1.5.11


I had such great hopes for this thread.  "Alas, poor Yorick! I 
knew him, Horatio ..."


On Thu, Jul 12, 2007 at 11:00:54AM -0400, Greg Smith wrote:
> On Thu, 12 Jul 2007, Gregory Stark wrote:
> 
> >In any case I wouldn't think the use case for a feature like this would
> >actually apply in the case of a benchmark.
> 
> I've also seen a tiny setting for commit_delay (like the 10 they used) as 
> helping improve throughput under a heavy commit load with many processors. 
> I'm not sure why a quick yield of the processor at that point helps, but 
> there seem to be cases where it does.  Don't think it has anything to do 
> with the originally intended use for this parameter, probably some sort of 
> OS scheduler quirk.
> 
> >The use case where something like this is needed is where there are not 
> >enough concurrent requests to keep the server busy during the fsync of 
> >the wal.
> 
> I've actually finished an long investigation of this recently that will be 
> on my web page soon.  On a non-caching controller where you'd think 
> there's the most benefit here, I was only able to get about 10% more 
> commits at low client loads by setting the delay to about 1/2 of the fsync 
> time, and a few percent more at high loads by setting a delay longer than 
> the fsync time.  It's really a slippery setting though--very easy to set 
> in a way that will degrade performance significantly if you're not very 
> systematic about testing it many times at various client counts.
> 
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match