Skip site navigation (1) Skip section navigation (2)

Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Stone <mstone+postgres(at)mathom(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal
Date: 2007-05-16 21:30:51
Message-ID: 7776.1179351051@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-performance
Michael Stone <mstone+postgres(at)mathom(dot)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

In response to

pgsql-docs by date

Next:From: Alvaro HerreraDate: 2007-05-16 21:41:30
Subject: Re: [DOCS] Autovacuum and XID wraparound
Previous:From: Alvaro HerreraDate: 2007-05-16 21:25:50
Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

pgsql-performance by date

Next:From: Mark KirkwoodDate: 2007-05-16 23:28:30
Subject: Re: Disk Fills Up and fsck "Compresses" it
Previous:From: Alvaro HerreraDate: 2007-05-16 21:25:50
Subject: Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group