Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 7BD0D9FB3F7
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 16 May 2007 13:17:13 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 50611-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 16 May 2007 13:16:51 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from noel.decibel.org (noel.decibel.org [67.100.216.10])
	by postgresql.org (Postfix) with ESMTP id 546439FB35D
	for <pgsql-performance@postgresql.org>;
	Wed, 16 May 2007 13:17:08 -0300 (ADT)
Received: by noel.decibel.org (Postfix, from userid 1001)
	id 2BBA0564EB; Wed, 16 May 2007 11:17:07 -0500 (CDT)
Received: (hashcash-sendmail, from uid 1001); Wed, 16 May 2007 11:17:02 -0500
Date: Wed, 16 May 2007 11:17:02 -0500
From: "Jim C. Nasby" <decibel@decibel.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Guillaume Cottenceau <gc@mnc.ch>,
	Michael Stone <mstone+postgres@mathom.us>, pgsql-performance@postgresql.org
Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement
 proposal
Message-ID: <20070516161702.GN14548@nasby.net>
References: <87lkfqavg9.fsf@meuh.mnc.lan> <20070515174427.GG1785@mathom.us>
	<87hcqdb4g5.fsf@meuh.mnc.lan> <20070516154809.GL14548@nasby.net>
	<877ir892ss.fsf@meuh.mnc.lan>
	<20070516160926.GX4582@alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070516160926.GX4582@alvh.no-ip.org>
X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64
X-Distributed: Join the Effort!  http://www.distributed.net
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Hashcash: 
 1:20:070516:alvherre@commandprompt.com::FXJc/K6lBVOF2oIR:00000000000
	000000000000000000000000268O
X-Hashcash: 1:20:070516:gc@mnc.ch::AcdPWf35g5KWCAn6:0000000087SO
X-Hashcash: 
 1:20:070516:mstone+postgres@mathom.us::0a9dS1NczVUgta5n:000000000000
	0000000000000000000000001VzU
X-Hashcash: 
 1:20:070516:pgsql-performance@postgresql.org::/RkJGRvdxSeeFYOk:00000
	0000000000000000000000003T6C
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200705/290
X-Sequence-Number: 24680

On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote:
> Guillaume Cottenceau wrote:
> > "Jim C. Nasby" <decibel 'at' decibel.org> writes:
> > 
> > > On Wed, May 16, 2007 at 09:41:46AM +0200, Guillaume Cottenceau wrote:
> > 
> > [...]
> > 
> > > > Come on, I don't suggest to remove several bold warnings about
> > > > it, the best one being "Therefore, frequently using VACUUM FULL
> > > > can have an extremely negative effect on the performance of
> > > > concurrent database queries." My point is to add the few
> > > > additional mentions; I don't think the claims that VACUUM FULL
> > > > physically compacts the data, and might be useful in case of too
> > > > long time with infrequent VACUUM are incorrect, are they?
> > > 
> > > Unfortunately they are, to a degree. VACUUM FULL can create a
> > > substantial amount of churn in the indexes, resulting in bloated
> > > indexes. So often you have to REINDEX after you VACUUM FULL.
> > 
> > Ok, VACUUM FULL does his job (it physically compacts the data and
> > might be useful in case of too long time with infrequent VACUUM),
> > but we are going to not talk about it because we often needs a
> > REINDEX after it? The natural conclusion would rather be to
> > document the fact than REINDEX is needed after VACUUM FULL, isn't
> > it?
> 
> Maybe, but we should also mention that CLUSTER is a likely faster
> workaround.

What this boils down to is that there should probably be a separate
subsection that deals with "Oh noes! My tables are too big!"
-- 
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)