To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: Re: WIP patch for latestCompletedXid method of computing snapshot
 xmax
In-Reply-To: <28198.1189282917@sss.pgh.pa.us> (Tom Lane's message of "Sat\,
	08 Sep 2007 16\:21\:57 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <3018.1189214811@sss.pgh.pa.us> <28198.1189282917@sss.pgh.pa.us>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Sat, 08 Sep 2007 22:39:45 +0100
Message-ID: <87r6l8x2e6.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> My desktop machine has a single consumer-grade IDE drive, and even with
> fsync off and synchronous_commit off, it can barely make 190 tps sustained
> pgbench throughput --- it's just disk write bound all the time. On a run
> with 8 clients, 10000 transactions per client, DB scale factor 25, I get
> this distribution of transaction times from CVS HEAD:

Wouldn't you expect to see more of an effect on cpu-bound environments? Is
there any i/o going on while these locks are being held? I suppose there's a
WAL commit record that has to be synced?

Have you tried with a smaller scale factor?

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