Re: Why vacuum?

Tim Allen wrote:
> 
> On Thu, 14 Dec 2000, Christopher Kings-Lynne wrote:
> 
> > Plenty of other databases need to be 'vacuumed'.  For instance, if you have
> > an ms access database with 5 MB of data in it, and then delete all the data,
> > leaving only the forms, etc - you will be left with a 5MB mdb file still!
> >
> > If you then run 'Compact Database' (which is another word for 'vacuum'), the
> > mdb file will be reduced down to 500k...
> 
> Ooh... Hope MS Access isn't going to be taken seriously as a benchmark
> here :-). The same is also true of MapInfo, by the way, but I'm not
> holding that up as a benchmark either ;-).

:-)

I think that the non-overwriting storage manager actually bought a lot
more for PostgreSQL than it does for MS Access.

In earlier versions of PostgreSQL it was possible to "time travel" your
database and so run your query agains the database as it was at a
particular time / date.  This advanced feature turns out to be useful in
very few situations, and is very expensive in terms of storage.

Still, "if it works, don't fix it" also applies.  The PostgreSQL storage
manager is quite efficient as it is now, and most of us do have quiet
periods when we can safely vacuum the database, which is why it has had
to wait until now.

This will be quite a big change for 7.2, and getting the performance
right will no doubt challenge these hackers whom we are all greatly
indebted to.

Cheers,                Andrew.
-- 
_____________________________________________________________________          Andrew McMillan, e-mail:
Andrew@catalyst.net.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267