Re: BUG #17942: vacuumdb doesn't populate extended statistics on partitioned tables

At Fri, 26 May 2023 14:48:30 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Fri, May 26, 2023 at 09:15:36AM +0900, Kyotaro Horiguchi wrote:
> > It seems to be exactly the same as ANALYZE, though. I'm a bit unclear
> > about our perspective on this SQL command's behavior.
>
> Sorry for being a bit unclear here. When dealing with partitioned
> tables, a database-wide ANALYZE processes the partitions individually
> as well as a full partition/inheritance tree.
>
> My point is slightly different though: your suggestion of adding
> RELKIND_PARTITIONED_TABLE to the filter added in vacuumdb would work
> for -Z, but it would cause the vacuum code path of vacuumdb to process
> more than once all the partitions in a single run. For instance, take
> this schema:
..
> `vacuumdb` would now list both parent_list and child_list, making
> child_list being vacuumed twice, which is not necessary. In order to
> get a behavior in parity with the SQL commands ANALYZE, VACUUM and
> VACUUM ANALYZE, we need to be more careful about the addition of
> RELKIND_PARTITIONED_TABLE to the filtering clause.

Ah, thanks. The difference lies in how VACUUM and vacuumdb handle
table names. VACUUM collects all names automatically, while the
vacuumdb specifies individual table names. The difference in handling
table names seems to be due to vacuumdb's certain options that need to
be checked against each table at the client side, specifically
--min-xid-age and min-mxid-age.

It might be nice if we included these options in VACUUM/ANALYZE's
syntax. Then vacuumdb wouldn't have to explicity gather table names.

On the other hand, regarding the existing versions. It would make
sense to allow partitioned tables only for analyze-only
cases. However, in the case of vacuum-analyze, we rather need to
exclude children. Therefore, it might be a better approach to always
exlclude children from the target relation list only if the parent is
present in the list. Anyway, I don't find a simple way to do that for
now.

So, the simplest measure for the issue would be to add the description
about the restriction to the documentation..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center