On 2015/03/17 5:18, Tom Lane wrote: > 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.
That seems like a good idea. Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers