Re: Plans for solving the VACUUM problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: "The Hermit Hacker" <scrappy(at)hub(dot)org>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Plans for solving the VACUUM problem
Date: 2001-05-21 14:06:35
Message-ID: 24896.990453995@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> writes:
> 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.
The index cleanup method I've proposed should be substantially
more efficient than the existing code, as well.

> 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
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.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-05-21 14:44:42 AW: Plans for solving the VACUUM problem
Previous Message Zak McGregor 2001-05-21 14:04:25 Re: Queries across multiple databases (was: SELECT from a table in another database).