Are extended statistics intentionally not propagated to partitions?

From: JoongHyuk Shin <sjh910805(at)gmail(dot)com>
To: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Are extended statistics intentionally not propagated to partitions?
Date: 2026-05-11 05:27:58
Message-ID: CACSdjfPmTpENLZ+5ZbERsR-qToDrV6rs+40FAuE=8UhAn95vvQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On a prior thread about owner assignment between INDEX and STATISTICS
(
https://www.postgresql.org/message-id/CACSdjfOyVWALYwb4QrLhAurqo5Ft9XU6zc6SSe%3D2FoG1DO0WWg%40mail.gmail.com
),
the explanation
(https://www.postgresql.org/message-id/2119849.1773605379@sss.pgh.pa.us)
was that statistics objects are not always tied to a single table
(and cross-table statistics are a long-term direction). That
answered the owner question, but I noticed a related thing.

CREATE STATISTICS on a partitioned parent does not propagate to
partitions. Unlike CREATE INDEX, which recurses via DefineIndex()
in indexcmds.c, CreateStatistics() in statscmds.c has no recursion;
the object is created only on the parent.

After partition pruning the planner reads stats off the child, which
has no user-defined stats, so operators have to CREATE STATISTICS on
each child manually.

I followed up on the same thread in April, but the patch on that
thread had been withdrawn and the discussion was dormant by then, so
it likely didn't reach a wider audience.

Is the non-propagation intentional or simply not implemented yet?
If "create stats per partition yourself" is the answer, that is
fine. Just confirming.

--
JH Shin

Browse pgsql-hackers by date

  From Date Subject
Next Message Nitin Motiani 2026-05-11 05:34:08 Re: Adding pg_dump flag for parallel export to pipes
Previous Message solaimurugan vellaipandiyan 2026-05-11 05:20:20 Re: pull-up subquery if JOIN-ON contains refs to upper-query