Re: Future directions for inheritance-hierarchy statistics

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.1425686096@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