| 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
| 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 |