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 45F69AEA.7050206@enterprisedb.com
Whole thread Raw
In response to Re: Recalculating OldestXmin in a long-running vacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Recalculating OldestXmin in a long-running vacuum  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
>> 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.
>
> Maybe because of increased contention of ProcArrayLock?  (I assume you
> are using that, althought I haven't seen the patch)

I am, but I doubt that's it. The response times are dominated by I/O, so
any increase in lock contention would hardly show up. And the patch is
only adding one GetOldestXmin call every 1000 scanned pages, which is
nothing compared to the thousands of GetSnapshot calls the normal
transactions are issuing per minute.

The patch must have changed the I/O pattern in some subtle way.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Recalculating OldestXmin in a long-running vacuum
Next
From: Heikki Linnakangas
Date:
Subject: Re: Recalculating OldestXmin in a long-running vacuum