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
Date: Fri, 13 Jul 2007 08:08:13 -0400
Message-ID: <20070713120813.GC5611@cns.vt.edu> (raw)
In-Reply-To: <Pine.GSO.4.64.0707121038120.21795@westnet.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stellr@cns.vt.edu, gsmith@gregsmith.com
Subject: Re: PostgreSQL publishes first real benchmark
In-Reply-To: <20070713120813.GC5611@cns.vt.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox