Re: Why vacuum?

* Ross J. Reedstrom <reedstrm(at)rice(dot)edu> [001214 07:57] wrote:
> On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
> >
> > They all have an overwriting storage manager. The current storage manager
> > of PostgreSQL is non overwriting, which has other advantages.
> >
> > There seem to be 2 answers to the problem:
> > 1. change to an overwrite storage manager
> > 2. make vacuum concurrent capable
> >
> > The tendency here seems to be towards an improved smgr.
> > But, it is currently extremely cheap to calculate where a new row
> > needs to be located physically. This task is *a lot* more expensive
> > in an overwrite smgr. It needs to maintain a list of pages with free slots,
> > which has all sorts of concurrency and persistence problems.
> >
>
> Not to mention the recent thread here about people recovering data that
> was accidently deleted, or from damaged db files: the old tuples serve
> as redundant backup, in a way. Not a real compelling reason to keep a
> non-overwriting smgr, but still a surprise bonus for those who need it.

One could make vacuum optional such that it either:

1) always overwrites
2) will not overwrite data until a vacuum is called (perhaps with
a date option to specify how much deleted data you wish to
reclaim) data can be marked free but not free for re-use
until vacuum is run.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."