"Josh Berkus" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
