To: "Josh Berkus" <josh@agliodbs.com>
Cc: <pgsql-hackers@postgresql.org>, "Markus Schiltknecht" <markus@bluegap.ch>,
	"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: WIP patch for latestCompletedXid method of computing snapshot
 xmax
In-Reply-To: <200709081418.35059.josh@agliodbs.com> (Josh Berkus's message of
	"Sat\, 8 Sep 2007 14\:18\:34 -0700")
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>
	<46E30EB4.7020304@bluegap.ch> <200709081418.35059.josh@agliodbs.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Sat, 08 Sep 2007 22:51:18 +0100
Message-ID: <87myvwx1ux.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


"Josh Berkus" <josh@agliodbs.com> writes:

> Hmmm.  Your results are withing the margin of error for DBT2, so they show no 
> real difference.  What we need for this is a heavy-read workload, though; on 
> a workload like DBT2 (which is mostly writes) I wouldn't expect lazy-XID to 
> help much.

The TPM is definitely within the margin of error but the 90th percentile
response times seem worrisome. But they're already over 5s which are TPC-C
failures. From what we've seen when you push the scale factor too high until
those numbers are even close to 5s you get very unstable results. 

The published benchmarks seem to keep the max around 5s which puts the 90th
percentile around half that. That seems overly conservative but I wonder what
reason they have for doing it that way.

> I'll see if I can find something appropriate.  Maybe Jan's TPC-W 
> implementation?

We could just rejigger the percentages on the transactions. I think Stock
Level and Order Status are entirely read-only but I would have to check. Stock
Level is a very intensive query though so I wouldn't suggest raising the
percentage on that.

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