Another point that this example raises is that letting autoanalyze ignore partition parent tables is not just a minor problem, but a potentially serious bug, causing very poor plan choices to be made for any nontrivial queries involving partitioned tables.
regards, tom lane
I ran into this issue frequently with pg_partman well before native partitioning. It's why I'd initially had the internal maintenance process run an analyze from the parent table whenever a new child table was made. Otherwise constraint exclusion didn't always work right. But it began causing too much of an issue with the maintenance runs because really large partition sets would then cause maintenance to take a really, really long time sometimes, potentially holding locks that could block normal table usage. So as of PG11 I no longer do the analyze by default, but it can still be turned on.
If there was some way to have autoanalyze kick in on the parent whenever a new child table is created in a set, that would probably help greatly. Could run with the same priority as the normal autoanalyze, so queries that would come in that require a higher lock could cancel it (assuming that's how that works?) and it could resume later. But something really does need to be done here to keep set-wide stats current so the exclusion/pruning process work better.
