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
