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@mascari.com

-----Original Message-----
From:    Tom Lane [SMTP:tgl@sss.pgh.pa.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
entryfor 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