Re: New VACUUM FULL

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: New VACUUM FULL
Date: 2009-11-15 01:26:38
Message-ID: 1258248398.18130.86.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2009-11-14 at 19:25 -0500, Tom Lane wrote:
> As a rule of thumb, I'd recommend keeping as much complexity as possible
> *out* of gram.y. It's best if that code just reports the facts, ie what
> options the user entered. Deriving conclusions from that (like what
> default behaviors should be used) is best done later. One example of
> why is that if you want the defaults to depend on GUC settings then
> that logic must *not* happen in gram.y, since the parse tree might
> outlive the current GUC settings.

I was referring to (in vacuum()):

+ if (vacstmt->options & (VACOPT_INPLACE | VACOPT_REPLACE |
VACOPT_FREEZE))
+ vacstmt->options |= VACOPT_VACUUM;
+ if (vacstmt->va_cols)
+ vacstmt->options |= VACOPT_ANALYZE;

I think what you say applies to VACOPT_ANALYZE, which is implied when
columns are supplied by the user but ANALYZE is not specified
explicitly. In that case it should be set in vacuum() but not in gram.y
(unless specified by the user).

However, for VACOPT_VACUUM, I think that's still in the territory of
gram.y.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-11-15 02:38:17 Re: TRIGGER with WHEN clause
Previous Message Robert Haas 2009-11-15 01:22:42 Re: patch - per-tablespace random_page_cost/seq_page_cost