Re: New VACUUM FULL
От | Jeff Davis |
---|---|
Тема | Re: New VACUUM FULL |
Дата | |
Msg-id | 1258248398.18130.86.camel@jdavis обсуждение исходный текст |
Ответ на | Re: New VACUUM FULL (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: