Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id TAA91649
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 22 Nov 1999 19:08:19 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA25738;
	Mon, 22 Nov 1999 19:06:50 -0500 (EST)
To: Peter Mount <peter@retep.org.uk>
cc: Pablo Saul Salazar - CESERCOMP <ssalazar@goliat.espol.edu.ec>,
	pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] table very big !!!!! 
In-reply-to: Your message of Mon, 22 Nov 1999 20:37:27 +0000 (GMT)
	<Pine.LNX.4.10.9911222036200.19044-100000@maidast.retep.org.uk>
Date: Mon, 22 Nov 1999 19:06:49 -0500
Message-ID: <25736.943315609@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Mount <peter@retep.org.uk> writes:
> Ah, try running first vacuum; then vacuum analyze. The first one will
> truncate the table removing the wasted space. The second simply rebuilds
> some statistics about the table.

This is not right --- AFAICT, vacuum *always* runs the compaction phase.
You can allow or skip the stats-gathering phase by specifying "analyze"
or not, but "vacuum analyze" implies "vacuum".

It sounds like Pablo has a problem with vacuum not doing what it is
supposed to ... has anyone else ever seen that?  It's a new one on me.

			regards, tom lane