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