RE: Plans for solving the VACUUM problem

> > It probably will not cause more IO than vacuum does right now.
> > But unfortunately it will not reduce that IO.
>
> Uh ... what? Certainly it will reduce the total cost of vacuum,
> because it won't bother to try to move tuples to fill holes.

Oh, you're right here, but daemon will most likely read data files
again and again with in-memory FSM. Also, if we'll do partial table
scans then we'll probably re-read indices > 1 time.

> The index cleanup method I've proposed should be substantially
> more efficient than the existing code, as well.

Not in IO area.

> > My point is that we'll need in dynamic cleanup anyway and UNDO is
> > what should be implemented for dynamic cleanup of aborted changes.
>
> UNDO might offer some other benefits, but I doubt that it will allow
> us to eliminate VACUUM completely. To do that, you would need to

I never told this -:)

> keep track of free space using exact, persistent (on-disk) bookkeeping
> data structures. The overhead of that will be very substantial: more,
> I predict, than the approximate approach I proposed.

I doubt that "big guys" use in-memory FSM. If they were able to do this...

Vadim