Re: Recalculating OldestXmin in a long-running vacuum

Gregory Stark wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> 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.

Hmm. Yeah, maybe it'll get better when we get that fixed..

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

The size did reach a steady state about half-way through the test, see
the logs here:

patched
http://community.enterprisedb.com/oldestxmin/92/server/relsizes.log

unpatched
http://community.enterprisedb.com/oldestxmin/93/server/relsizes.log

The test was a success in that sense, the patch did reduce the steady
state size of the stock table.

Maybe we would see a gain in transactions per minute or response times
if we traded off the smaller table size to run vacuum slightly less
frequently.. But as I said I don't want to spend time running more tests
for what seems like a small benefit.

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