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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
