Hello Greg,
> At the risk of forking this thread... I think there's actually a
> planner estimation bug here too.
>
I think that is not a bug. The estimation error occurred there were no
parent's statistics. We should run analyze on *partitioned table*.
Here is your test case:
create table p (i
At the risk of forking this thread... I think there's actually a
planner estimation bug here too.
Consider this test case of a simple partitioned table and a simple
join. The cardinality estimates for each partition and the Append node
are all perfectly accurate. But the estimate for the join is w
Hi Greg,
On Tue, Oct 1, 2019 at 4:03 AM Greg Stark wrote:
>
> Actually -- I'm sorry to followup to myself (twice) -- but that's
> wrong. That Todo item predates the modern partitioning code. It came
> from when the partitioned statistics were added for inheritance trees.
> The resulting comment a
Actually -- I'm sorry to followup to myself (twice) -- but that's
wrong. That Todo item predates the modern partitioning code. It came
from when the partitioned statistics were added for inheritance trees.
The resulting comment almost doesn't make sense any more since it
talks about updates to the
Actually I did just find it in the To-do wiki:
Have autoanalyze of parent tables occur when child tables are modified
- http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php
On Mon., Sep. 30, 2019, 1:48 p.m. Greg Stark, wrote:
> So we now support `ANALYZE partitioned_table
