To: Michael Stone <mstone+postgres@mathom.us>
cc: pgsql-performance@postgresql.org
Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement
	proposal
In-reply-to: <20070516211713.GJ1785@mathom.us> 
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>
	<20070516162035.GI1785@mathom.us>
	<608xbotve5.fsf@dba2.int.libertyrms.com>
	<20070516211713.GJ1785@mathom.us>
Comments: In-reply-to Michael Stone <mstone+postgres@mathom.us>
	message dated "Wed, 16 May 2007 17:17:16 -0400"
Date: Wed, 16 May 2007 17:30:51 -0400
Message-ID: <7776.1179351051@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Stone <mstone+postgres@mathom.us> writes:
> On Wed, May 16, 2007 at 03:34:42PM -0400, Chris Browne wrote:
>> If CLUSTER is faster than VACUUM FULL (and if it isn't, in all cases,
>> it *frequently* is, and probably will be, nearly always, soon), then
>> it's a faster workaround.

> Cluster reorders the table. If a table doesn't have any dead rows and 
> you tell someone to run cluster or vacuum full, the vaccuum basically 
> won't do anything and the cluster will reorder the whole table. Cluster 
> is great for certain access patterns, but I've been noticing this odd 
> tendency lately to treat it like a silver bullet.

Sure, but VACUUM FULL looks even less like a silver bullet.

There's been talk of providing an operation that uses the same
infrastructure as CLUSTER, but doesn't make any attempt to re-order the
table: just seqscan the old heap, transfer still-live tuples into a new
heap, then rebuild indexes from scratch.  This is clearly going to be a
lot faster than a VACUUM FULL under conditions in which the latter would
have to move most of the tuples.  Heikki just fixed one of the major
objections to it (ie, CLUSTER not being MVCC-safe).  The other objection
is that peak transient disk space usage could be much higher than VACUUM
FULL's, but still for a lot of scenarios this'd be better.

			regards, tom lane