> > 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
