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

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:
CREATE TABLE parent_list (id int) PARTITION BY LIST (id);
                                                   
CREATE TABLE child_list PARTITION OF parent_list
  FOR VALUES IN (1, 2);
                                                 

`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.
--
Michael