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
So we now support `ANALYZE partitioned_table` which will gather statistics
for the main table by gathering stats from all the partitions.
However as far as I can tell autovacuum will never actually trigger this
analyze. Because we never generate any update records for the parent table
in the stati
