Re: New VACUUM FULL
От | Simon Riggs |
---|---|
Тема | Re: New VACUUM FULL |
Дата | |
Msg-id | 1258019485.14054.133.camel@ebony обсуждение исходный текст |
Ответ на | New VACUUM FULL (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Список | pgsql-hackers |
On Tue, 2009-10-27 at 13:55 +0900, Itagaki Takahiro wrote: > Here is a patch to support "rewrite" version of VACUUM FULL. > It was called "VACUUM REWRITE" in the past disucussin, > but I choose the following syntax for now: > > VACUUM ( FULL [ INPLACE | REPLACE ] ) [ table_name ] > > The reason is to contrast the new REPLACE behavior with the old INPLACE > behavior. I cannot find any good terms of opposite meaning of REWRITE. > > The new version works like as CLUSTER USING ctid or rewriting in > ALTER TABLE. It must be faster than them if we have many dead tuples > and are not interested in physical order of tuples. > > We still need traditional VACUUM FULL behavior for system catalog because > we cannot change relfilenode for them. Also, VACUUM FULL REPLACE is not > always better than traditional VACUUM FULL; the new version requires > additional disk space and might be slower if we have a few dead tuples. > > "VACUUM FULL" and "VACUUM (FULL)" are synonyms for "VACUUM (FULL REPLACE)", > but if the target table is s system catalog, instead "FULL INPLACE" is > used automatically. > If this approach is reasonable, I'll go for other supplemental parts. > (documentations, vacuumdb, etc.) Rough approach looks fine to me. The internal logic is fairly hard to read. I'd suggest you have option flags VACUUM_FULL and VACUUM_REPLACE, rather than VACUUM_INPLACE and VACUUM_REPLACE. So VACUUM_REPLACE can only be set iff VACUUM_FULL. That will reduce much of the logic. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: