Re: [HACKERS] Autovacuum Improvements

Darcy Buskermolen wrote:
> [snip]
>
> Another thought, is it at all possible to do a partial vacuum? ie spend the
> next 30 minutes vacuuming foo table, and update the fsm with what hew have
> learned over the 30 mins, even if we have not done a full table scan ?
>
There was a proposal for this, but it was dropped on 2 grounds.
1. partial vacuum would mean that parts of the table are missed, the
user could never vacuum certain parts and transaction wraparound would
get you. You may also have other performance issues as you forgot
certian parts of the table

2. Index cleanup is the most expensive part of vacuum. So doing a
partial vacuum actually means more I/O as you have to do index cleanup
more often.

If we are talking about autovacuum, 1 doesn't become so much of an issue
as you just make the autovacuum remember what parts of the table it's
vacuumed. This really has great power when you have a dead space map.

Item 2 will still be an issue. But if you define "partial" as either
fill maintenance_work_mem, or finish the table, you are not increasing
I/O at all. As when maintenance work mem is full, you have to cleanup
all the indexes anyway. This is really more like VACUUM SINGLE, but the
same principal applies.

I believe all planning really needs to think about how a dead space map
will effect what vacuum is going to be doing in the future.

Strange idea that I haven't researched, Given Vacuum can't be run in a
transaction, it is possible at a certain point to quit the current
transaction and start another one. There has been much chat and now a
TODO item about allowing multiple vacuums to not starve small tables.
But if a big table has a long running vacuum the vacuum of the small
table won't be effective anyway will it? If vacuum of a big table was
done in multiple transactions you could reduce the effect of long
running vacuum. I'm not sure how this effects the rest of the system
thought.

Russell Smith
>
>