Re: Recalculating OldestXmin in a long-running vacuum

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

> Tom Lane wrote:
>
> > In any case I'd like to see some evidence of significant real-world
> > benefit before adding such a conceptual wart ...
>
> I've asked our testers to do a TPC-C run with and without the
> patch. I'm not expecting it to make a huge difference there, but if you're
> using a big cost delay, it could make quite a difference for such a simple
> thing.

I think the key here is that it removes the size of the table from the list of
factors that govern the steady-state. Currently as the table grows the maximum
age of the snapshot vacuum uses gets older too which means a greater
percentage of the table is dedicated to dead tuple overhead. (which in turn
means a larger table which means an even greater percentage of dead tuples...)

With the patch the size of the table is no longer a factor. As long as the
work vacuum has on a given page can keep up with the rate of creating dead
tuples then it won't matter how large the table is. The only factors that
determine the steady state are the rate of creation of dead tuples and the
rate at which vacuum can process them.

Unfortunately indexes, again, mean that's not entirely true. As the table
grows the indexes will grow as well and that will slow vacuum down. Though
indexes are usually smaller than tables.

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