Re: Recalculating OldestXmin in a long-running vacuum - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: Recalculating OldestXmin in a long-running vacuum
Date
Msg-id 45F687CB.9030802@enterprisedb.com
Whole thread Raw
In response to Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Recalculating OldestXmin in a long-running vacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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

pgsql-patches by date:

Previous
From: Joachim Wieland
Date:
Subject: Re: guc patch: Make variables fall back to default values
Next
From: Alvaro Herrera
Date:
Subject: Re: Recalculating OldestXmin in a long-running vacuum