BUG #17942: vacuumdb doesn't populate extended statistics on partitioned tables - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #17942: vacuumdb doesn't populate extended statistics on partitioned tables
Date
Msg-id 17942-50aa28accc2e412c@postgresql.org
Whole thread Raw
Responses Re: BUG #17942: vacuumdb doesn't populate extended statistics on partitioned tables
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      17942
Logged by:          Henri Chapelle
Email address:      henri.chapelle@dbandmore.com
PostgreSQL version: 13.8
Operating system:   Centos 7
Description:

Hi,
We recently added extended statistics on big partitioned tables in
Postgresql 13.8.
While runing analyze tablename or vacuumdb -Z -t tablename populate extended
statistics, the vacuumdb -Z command (without -t) doesn't process the parent
table during the analyze.
We created a script to collecte table names and run the analyze table by
table.
Is it expected ?
The documentation mentions that autovacuum will not process the parent table
due to no data in the parent table.
But vacuumdb should process all tables, right ?

Here is an example :
CREATE TABLE people (
    id int not null,
    birth_date date not null,
    country_code character(2) not null,
    name text
) PARTITION BY RANGE (birth_date);

CREATE TABLE people_y2000 PARTITION OF people
    FOR VALUES FROM ('2000-01-01') TO ('2001-01-01');

CREATE TABLE people_y2001 PARTITION OF people
    FOR VALUES FROM ('2001-01-01') TO ('2002-01-01');

CREATE TABLE people_y2002 PARTITION OF people
    FOR VALUES FROM ('2002-01-01') TO ('2003-01-01');


INSERT INTO people (id, birth_date, country_code, name) VALUES (1,
'2000-01-01', 'US', 'John'), (2, '2000-02-02', 'IT', 'Jane'), (3,
'2001-03-03', 'FR', 'Bob');

create statistics people_stat_001 on birth_date, name from people;

vacuumdb -Z -t people : -> ok extende stats collected
vacuumdb -Z : -> no extended stats and analyze much faster


pgsql-bugs by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Logical Replica ReorderBuffer Size Accounting Issues
Next
From: "Wei Wang (Fujitsu)"
Date:
Subject: RE: Logical Replica ReorderBuffer Size Accounting Issues