"Mikko Partio" <mpartio@xxxxxxxxx> writes: > Interesting. What is planned substitute for VACUUM FULL? CLUSTER? What's been discussed is something that works roughly like CLUSTER but doesn't bother to sort the data any particular way (ie, just do a seqscan not an indexscan in the data-copying phase). This would certainly dominate VACUUM FULL in contexts where you've removed a large fraction of the rows. In cases where you haven't, the large transient space requirement (2x the table size) would be objectionable, but it's not real clear why you need a VACUUM FULL rather than plain VACUUM in such cases anyway. A lot of the context for this arises from recent and planned improvements, notably (1) CLUSTER is MVCC-safe now, removing one of the core arguments for not using it for routine cleanup. (2) Planned fixes like the dead space map will substantially reduce the cost of running frequent plain vacuums. That together with autovacuum (which we could make more aggressive in consequence) should help to avoid getting into situations where VACUUM FULL is needed in the first place. We certainly couldn't have considered eliminating VACUUM FULL before this, but it's starting to seem a viable option to me. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
