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


Thu, 17 May 2001 20:52:51 -0400
Mike Mascari <mascarm@mascari.com>
RE: Plans for solving the VACUUM problem
Mike Mascari <mascarm@mascari.com> writes:
> 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?

In the proposal as given, a heap file would be truncated if (a) it
has at least one totally empty block at the end, and (b) no other
transaction is touching the table at the instant that VACUUM is
ready to truncate it.

This would probably be fairly infrequently true, especially for
heavily used tables, but if you believe in a "steady state" analysis
then that's just fine.  No point in handing blocks back to the OS
only to have to allocate them again soon.

We might want to try to tilt the FSM-driven reuse of freed space
to favor space near the start of the file and avoid end blocks.
Without that, you might never get totally free blocks at the end.

The same comments hold for index blocks, with the additional problem
that the index structure would make it almost impossible to drive usage
away from the physical end-of-file.  For btrees I think it'd be
sufficient if we could recycle empty blocks for use elsewhere in the
btree structure.  Actually shrinking the index probably won't happen
short of a REINDEX.

			regards, tom lane

Fri, 18 May 2001 01:02:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Plans for solving the VACUUM problem 