> 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
Agreed. I fight for UNDO, not against background vacuum -:)
> 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
Unfortunately, I think that we'll need in on-disk FSM and that FSM is
actually the most complex thing to do in "space reclamation" project.
> 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 ...
Yes.
Vadim
