Re: Recalculating OldestXmin in a long-running vacuum

Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> 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.
>
> So are you stopping work on the patch? I assume so.

Yes, at least for now. I can't believe the patch actually hurts
performance, but I'm not going to spend time investigating it.

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