Re: New VACUUM FULL

On Tue, 2009-12-22 at 18:11 +0900, Takahiro Itagaki wrote:
> 
> > Old VACUUM FULL was substantially faster than this on tables that
> had
> > nothing to remove.

> Yeah, that's why traditional VACUUM FULL is still kept as INPLACE
> vacuum.
> 
> > Please can you arrange for the cluster operation to skip rebuilding
> > indexes if the table is not reduced in size? 
> 
> Do you think we should dispose the rewritten table when we find the
> VACUUM FULL (or CLUSTER) is useless?  We could save the time to
> reindex,
> but we've already consumed time to rewrite tables. 

The main purpose of doing a new VF is to compact space, so its role has
slightly changed from earlier versions. We need much clearer docs about
this.

On a production system, it seems better to skip the re-indexing, which
could take a long, long time. I don't see any way to skip completely
re-writing the table though, other than scanning the table with a normal
VACUUM first, as old VF does. 

I would be inclined towards the idea that if somebody does a VF of a
whole database then we should look out for and optimise for tables with
no changes, but when operating on a single table we just do as
instructed and rebuild everything, including indexes. That seems like we
should do it, but we're running out of time.

For now, I think we can easily and should skip the index build, if
appropriate. That just takes a little reworking of code, which appears
necessary anyway. We should just document that this works a little
differently now and a complete db VF is now not either necessary or a
good thing. And running 
  VACUUM; REINDEX DATABASE foo;
will now be very pointless.

> It will be still
> slower than VACUUM FULL INPLACE because it is read-only.

Understood, lets document that.

-- 
 Simon Riggs           www.2ndQuadrant.com