Tom Lane wrote:
> I was just thinking of a GUC parameter: wait N milliseconds between
> pages, where N defaults to zero probably. A user who wants to run his
> vacuum as a background process could set N larger than zero. I don't
> believe we are anywhere near being able to automatically adjust the
> delay based on load, and even if we could, this would ignore the point
> you make above --- the user's intent has to matter as much as anything
> else.
I am slightly confused here. IIRC pg_autovacuum never did a vacuum full. At the
most it does vacuum /vacuum analyse, none of which chew disk bandwidth. And if
pg_autovacuum is running along with postmaster all the time, with aggressive
polling like 5 sec, the database should not accumulate any dead tuples nor it
would suffer xid wraparound as there are vacuum happening constantly.
What's left in above scenario? As long as all the requirements for pg_autovacuum
are met, namely setting it up, setting it up aggressively and tuning
postgresql.conf correctly, vacuum and related problems should be a thing in
past, at least as far as 7.4 and onwards is considered.
Of course RSM implementation for vacuum would still be much needed but right
now, it does not affect disk IO directly(except for tossing buffer cache out of
track that is).
What am I missing?
Shridhar