The Hermit Hacker <scrappy@hub.org> writes:
> If its an "experiment", shouldn't it be done outside of the main source
> tree, with adequate testing in a high load situation, with a patch
> released to the community for further testing/comments, before it is added
> to the source tree?
Mebbe we should've handled WAL that way too ;-)
Seriously, I don't think that my proposed changes need be treated with
quite that much suspicion. The only part that is really intrusive is
the shared-memory free-heap-space-management change. But AFAICT that
will be a necessary component of *any* approach to getting rid of
VACUUM. We've been arguing here, in essence, about whether a background
or on-line approach to finding free space will be more useful; but that
still leaves you with the question of what you do with the free space
after you've found it. Without some kind of shared free space map,
there's not anything you can do except have the process that found the
space do tuple moving and file truncation --- ie, VACUUM. So even if
I'm quite wrong about the effectiveness of a background VACUUM, the FSM
code will still be needed: an UNDO-style approach is also going to need
an FSM to do anything with the free space it finds. It's equally clear
that the index AMs have to support index tuple deletion without
exclusive lock, or we'll still have blocking problems during free-space
cleanup, no matter what drives that cleanup. The only part of what
I've proposed that might end up getting relegated to the scrap heap is
the "lazy vacuum" command itself, which will be a self-contained and
relatively small module (smaller than the present commands/vacuum.c,
for sure).
Besides which, Vadim has already said that he won't have time to do
anything about space reclamation before 7.2. So even if background
vacuum does end up getting superseded by something better, we're going
to need it for a release or two ...
regards, tom lane
