From: Gregory Stark <stark@enterprisedb.com>
To: "Alvaro Herrera" <alvherre@commandprompt.com>
Cc: "Scott Marlowe" <smarlowe@g2switchworks.com>,
	"Jim C. Nasby" <decibel@decibel.org>,
	"Zoltan Boszormenyi" <zb@cybertec.at>, "PFC" <lists@peufeu.com>,
	<pgsql-performance@postgresql.org>
Subject: Re: Postgres Benchmark Results
In-Reply-To: <20070522004737.GK6111@alvh.no-ip.org> (Alvaro Herrera's message
	of "Mon, 21 May 2007 20:47:37 -0400")
Organization: EnterpriseDB
References: <op.tsmrv71ecigqcu@apollo13> <46508CB9.1040404@cybertec.at>
	<20070521210125.GM62346@nasby.net>
	<46523925.9080901@g2switchworks.com>
	<20070522004737.GK6111@alvh.no-ip.org>
Date: Tue, 22 May 2007 09:03:56 +0100
Message-ID: <87lkfhl1xv.fsf@oxford.xeocode.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Alvaro Herrera" <alvherre@commandprompt.com> writes:

> Scott Marlowe wrote:
>> 
>> I thought you were limited to 250 or so COMMITS to disk per second, and 
>> since >1 client can be committed at once, you could do greater than 250 
>> tps, as long as you had >1 client providing input.  Or was I wrong?
>
> My impression is that you are correct in theory -- this is the "commit
> delay" feature.  But it seems that the feature does not work as well as
> one would like; and furthermore, it is disabled by default.

Even without commit delay a client will commit any pending WAL records when it
syncs the WAL. The clients waiting to commit their records will find it
already synced when they get woken up.

However as mentioned a while back in practice it doesn't work quite right and
you should expect to get 1/2 the expected performance. So even with 10 clients
you should expect to see 5*120 tps on a 7200 rpm drive and 5*250 tps on a
15kprm drive.

Heikki posted a patch that experimented with fixing this. Hopefully it'll be
fixed for 8.4.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com