One related thing I noticed.
Unlike CREATE INDEX, CREATE STATISTICS on a partitioned table does not propagate to child partitions.
Is that intentional, or simply not implemented yet?
In practice, if you create statistics on a partitioned parent and then EXPLAIN a WHERE query,
the planner doesn't use the stats because after partition pruning it looks at the child's statistics,
where none exist. You have to create statistics on each child explicitly to get the benefit.
If the answer is "create stats per partition yourself", that's fine.
Just wanted to confirm whether this is by design.
Thank you for the additional context, Tom. That makes the design intent much clearer.
Cross-table statistics, if realized, would be a significant improvement for join cardinality estimation; looking forward to seeing that develop.
Regards,
Joshua Shin
Shin Berg <sjh910805@gmail.com> writes:
> Thank you for the detailed feedback, Amit.
> You're right on both points. I had been comparing STATISTICS against INDEX
> and treating the difference as an inconsistency, but as you point out,
> INDEX ownership is special — it's tied to the table and intentionally not
> user-adjustable. STATISTICS follows the same ownership model as VIEW (the
> creator becomes the owner), which is consistent and by design.
One point that was not mentioned is that while indexes are necessarily
tied to a single table, statistics objects might not always be. The
long-term hope is to allow statistics on cross-table combinations of
columns, which is why the syntax was intentionally set up to look like
SELECT. So, just like views, it's reasonable to give them independent
ownership.
regards, tom lane
