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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
