Re: New VACUUM FULL

Here is an updated patch of rewriting vacuum based on vacuum options patch.
Documentations and vacuumdb modification (-i, --inplace) are added.

Jeff Davis  wrote:

> 1. Do we want to introduce syntax for INPLACE at all, if we are
> eventually going to remove the current mechanism?
> My opinion is that if we really still need the current in-place
> mechanism, then VACUUM (FULL) should use the current in-place mechanism;
> and VACUUM (FULL REWRITE) should use your new rewrite mechanism.

AFAIK, "VACUUM FULL" should behave as "REWRITE" in the past discussion.
Since we don't want users to use in-place FULL vacuum, so we will change
the default behavior of VACUUM FULL. There are some choices:

               
  1. VACUUM (FULL REPLACE) vs. VACUUM (FULL INPLACE)
  2. VACUUM (FULL)         vs. VACUUM (FULL INPLACE)
  3. VACUUM (REWRITE)      vs. VACUUM (FULL)
  4. VACUUM (FULL REWRITE) vs. VACUUM (FULL)
  5. Don't use SQL and use a GUC instead. (bool inplace_vacuum_full ?)

I choose a hybrid syntax of 1 + 2 in the patch,
but I'm not particular about it. What is the best?

> 2. Why do all of the following exist: VACOPT_FULL, VACOPT_REPLACE, and
> VACOPT_INPLACE? Shouldn't VACOPT_FULL be equivalent to one of the other
> two? This is essentially what Simon was getting at, I think.

 * FULL [REPLACE] := VACOPT_FULL
 * FULL INPLACE   := VACOPT_FULL + VACOPT_INPLACE

> 3. Some options are being set in vacuum() itself. It looks like the
> options should already be set in gram.y, so should that be an Assert
> instead? I think it's cleaner to set all of the options properly early
> on, rather than waiting until vacuum() to interpret the combinations.

I moved all of the logic into gram.y. vacuum() has only assert tests.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center