Re: Recalculating OldestXmin in a long-running vacuum

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:

>>>>> 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.

Isn't this exactly what you would expect? It will clean up more tuples so
it'll dirty more pages. Especially given the pessimal way vacuum's dirty
buffers are handled until Simon's patch to fix that goes in.

The benefit of the patch that we would expect to see is that you won't need to
run VACUUM as often. In the long term we would expect the stock table to grow
less too but I doubt these tests were long enough to demonstrate that effect.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com