A few days ago I posted a very-much-WIP patch for making the planner dynamically combine statistics for each member of an appendrel: http://www.postgresql.org/message-id/22598.1425686...@sss.pgh.pa.us
That patch was only intended to handle the case of an appendrel generated by a UNION ALL construct. But it occurs to me that we could easily change it to also apply to appendrels generated from inheritance trees. Then we'd no longer need the whole-inheritance-tree statistics that ANALYZE currently produces, because we'd only ever look at per-table statistics in pg_statistic. This would have one significant drawback, which is that planning for large inheritance trees (many children) would probably get noticeably slower. (But in the common case that constraint exclusion limits a query to scanning just one or a few children, the hit would be small.) On the other hand, there would be two very significant benefits. First, that we would automatically get statistics that account for partitions being eliminated by constraint exclusion, because only the non-eliminated partitions are present in the appendrel. And second, that we'd be able to forget the whole problem of getting autovacuum to create whole-inheritance-tree stats. Right now I'm doubtful that typical users are getting good up-to-date stats at all for queries of this sort, because autovacuum will only update those stats if it decides it needs to analyze the parent table. Which is commonly empty, so that there's never a reason to fire an analyze on it. (We'd left this as a problem to be solved later when we put in the whole-tree stats feature in 9.0, but no progress has been made on solving it.) So I think that going in this direction is clearly a win and we ought to pursue it. It's not happening for 9.5 of course, because there's still a great deal of work to do before anything like this would be committable. But I would like to establish a consensus that this would be a sensible thing to do in 9.6. The reason I bring it up now is that the inheritance-for-foreign-tables patch has some code that I don't much like for controlling what happens with those whole-tree stats when some of the children are foreign tables that lack ANALYZE support. If the long-term plan is that whole-tree stats are going away altogether, then it won't be terribly important exactly what happens in that case, so we can just do some simple/easy kluge in the short term and not have to have an argument about what's the best thing to do. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers