From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Markus Schiltknecht <markus(at)bluegap(dot)ch>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: WIP patch for latestCompletedXid method of computing snapshot xmax |
Date: | 2007-09-08 21:18:34 |
Message-ID: | 200709081418.35059.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Markus,
> I've just completed two dbt2 test runs on a mid-level system, with 4GB
> RAM and a 7 disk SATA RAID 1+0 w/ BBU. Once with code as of 2007/09/05
> 18:00 (which is *before* the first lazy xid commit) and once with cvs
> HEAD (2007/09/08 +latestCompletedXid.patch.
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.
I'll see if I can find something appropriate. Maybe Jan's TPC-W
implementation?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-09-08 21:19:34 | Re: Low hanging fruit in lazy-XID-assignment patch? |
Previous Message | Mark Mielke | 2007-09-08 21:14:09 | Re: Hash index todo list item |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-08 21:29:05 | Re: WIP patch for latestCompletedXid method of computing snapshot xmax |
Previous Message | Markus Schiltknecht | 2007-09-08 21:05:56 | Re: WIP patch for latestCompletedXid method of computing snapshot xmax |