From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: New VACUUM FULL |
Date: | 2009-11-12 09:51:25 |
Message-ID: | 1258019485.14054.133.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-11-12 10:04:32 | Re: next CommitFest |
Previous Message | Alexandra Roy | 2009-11-12 09:49:33 | Re: PostgreSQL 8.3.8 on AIX5.3 : compilation failed |