Re: WIP patch for latestCompletedXid method of computing snapshot xmax - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: WIP patch for latestCompletedXid method of computing snapshot xmax
Date
Msg-id 87myvwx1ux.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: WIP patch for latestCompletedXid method of computing snapshot xmax  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Kenneth Marshall
Date:
Subject: Re: Hash index todo list item
Next
From: apoc9009
Date:
Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)