From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <gsstark(at)mit(dot)edu>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Recalculating OldestXmin in a long-running vacuum |
Date: | 2007-03-13 11:15:23 |
Message-ID: | 45F687CB.9030802@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Was this revisited?
>
> Arranging the tests has taken me longer than I thought, but I now
> finally have the hardware and DBT-2 set up. I just finished a pair of 2h
> tests with autovacuum off, and continuous vacuum of the stock table. I'm
> trying to get the results uploaded on some public website so we can all
> see and discuss them.
I finally got around looking at this again.
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As expected, the steady-state of the stock table is smaller with the
patch. But only by ~2%, that's slightly less than I expected.
But what surprises me is that response times went up a with the patch. I
don't know why.
The full test results are here:
http://community.enterprisedb.com/oldestxmin/
92 was run with the patch, 93 without it.
BTW: The iostat chart clearly shows the vacuum WAL flush problem. The
WAL utilization jumps from ~20% to ~40% during the 2nd vacuum pass.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-03-13 12:27:41 | Re: Recalculating OldestXmin in a long-running vacuum |
Previous Message | Joachim Wieland | 2007-03-13 10:54:18 | Re: guc patch: Make variables fall back to default values |