Jan Wieck <JanWieck@yahoo.com> writes:
> I think the in-shared-mem FSM could have some max-per-table
> limit and the background VACUUM just skips the entire table
> as long as nobody reused any space.
I was toying with the notion of trying to use Vadim's "MNMB" idea
(see his description of the work he did for Perlstein last year);
that is, keep track of the lowest block number of any modified block
within each relation since the last VACUUM. Then VACUUM would only
have to scan from there to the end. This covers the totally-untouched-
relation case nicely, and also helps a lot for large rels that you're
mostly just adding to or perhaps updating recent additions.
The FSM could probably keep track of such info fairly easily, since
it will already be aware of which blocks it's told backends to try
to insert into. But it would have to be told about deletes too,
which would mean more FSM access traffic and more lock contention.
Another problem (given my current view of how FSM should work) is that
rels not being used at all would not be in FSM, or would age out of it,
and so you wouldn't know that you didn't need to vacuum them.
So I'm not sure yet if it's a good idea.
regards, tom lane
