Re: ANALYZE ONLY

David Rowley <dgrowleyml(at)gmail(dot)com>, 21 Ağu 2024 Çar, 01:53 tarihinde şunu
yazdı:

> On Wed, 21 Aug 2024 at 06:41, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
>
> Making it a command option means that the option would apply to all
> tables listed, whereas if it was more like an extended_relation_expr,
> the option would be applied per table listed in the command.
>
> 1. ANALYZE ONLY ptab, ptab2; -- gather stats on ptab but not on its
> partitions but get stats on ptab2 and stats on its partitions too.
> 2. ANALYZE ONLY ptab, ONLY ptab2; -- gather stats on ptab and ptab2
> without doing that on any of their partitions.
>

I believe we should go this route if we want this to be called "ONLY" so
that it would be consistent with other places too.

Whereas: "ANALYZE (ONLY) ptab, ptab2;" would always give you the
> behaviour of #2.
>

Havin it as an option would be easier to use when we have several partition
tables. But I agree that if we call it "ONLY ", it may be confusing and the
other approach would be appropriate.

> If we did it as a per-table option, then we'd need to consider what
> should happen if someone did: "VACUUM ONLY parttab;". Probably
> silently doing nothing wouldn't be good. Maybe a warning, akin to
> what's done in:
>
> postgres=# analyze (skip_locked) a;
> WARNING: skipping analyze of "a" --- lock not available
>

+1 to raising a warning message in that case instead of staying silent. We
might also not allow ONLY if ANALYZE is not present in VACUUM query and
raise an error. But that would require changes in grams.y and could
complicate things. So it may not be necessary and we may be fine with just
a warning.

Regards,
--
Melih Mutlu
Microsoft