RE: Plans for solving the VACUUM problem

Very neat. You mention that the truncation of both heap and index
relations is not necessarily mandatory. Under what conditions would
either of them be truncated?

Mike Mascari
mascarm(at)mascari(dot)com

-----Original Message-----
From: Tom Lane [SMTP:tgl(at)sss(dot)pgh(dot)pa(dot)us]

....

3. Lazy VACUUM processes a table in five stages:
A. Scan relation looking for dead tuples; accumulate a list of
their
TIDs, as well as info about existing free space. (This pass is
completely read-only and so incurs no WAL traffic.)
B. Remove index entries for the dead tuples. (See below for
details.)
C. Physically delete dead tuples and compact free space on their
pages.
D. Truncate any completely-empty pages at relation's end.
(Optional,
see below.)
E. Create/update FSM entry for the table.

...

Further out (possibly not for 7.2), we should also look at making the
index AMs responsible for shrinking indexes during deletion, or
perhaps
via a separate "vacuum index" API. This can be done without
exclusive
locks on the index --- the original Lehman & Yao concurrent-btrees
paper
didn't describe how, but more recent papers show how to do it. As
with
the main tables, I think it's sufficient to recycle freed space
within
the index, and not necessarily try to give it back to the OS.

...
regards, tom lane