Re: ANALYZE ONLY - Mailing list pgsql-hackers

From Melih Mutlu
Subject Re: ANALYZE ONLY
Date
Msg-id CAGPVpCSGwWQkU5DWoSFzZ3LPYqbWQZzi7cXWHsyYgvnsqWfYhA@mail.gmail.com
Whole thread Raw
In response to Re: ANALYZE ONLY  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: ANALYZE ONLY
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com>, 21 Ağu 2024 Çar, 01:53 tarihinde şunu yazdı:
On Wed, 21 Aug 2024 at 06:41, Robert Haas <robertmhaas@gmail.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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Next
From: Amit Kapila
Date:
Subject: Re: Conflict detection and logging in logical replication