Re: Future directions for inheritance-hierarchy statistics

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, you're ignoring the prospect of getting better estimates and hence
>> better plans through having stats that dynamically adapt to the set of
>> partitions being scanned. Given the lousy state of maintenance of
>> whole-tree stats, I really think that this consideration might outweigh
>> even a significant planning-time hit. Shaving planning time by producing
>> crappy estimates isn't usually a good tradeoff.

> Perhaps so, but I know that the planning time of large inheritance
> trees has been a major issue for some of EnterpriseDB's customers. In
> fact, EnterpriseDB has run into a number of customer situations where
> planning time even for non-inheritance queries is substantially higher
> than, shall we say, a competing commercial product. With inheritance,
> even people who aren't making comparisons with other products start to
> get unhappy. I've always been very pleased with the quality of plans
> that our planner generates, but it's becoming increasingly clear to me
> that at least one other product is able to provide good plans at a
> significantly lower CPU cost, and inheritance is particular trouble
> spot. I don't know exactly what we ought to do about that and perhaps
> it's to one side of the issue you're raising here, but I do think it's
> an issue that we (the PostgreSQL community) ought to be thinking
> about.

Well, we know that the current approach to inheritance isn't very well
attuned to standard partitioning situations, because it treats every
inheritance child as a de novo problem. I continue to maintain that
the right fix for that is a partitioning feature that forbids any schema
variation across partitions, which the planner would use to avoid doing
O(N) work when dealing with an N-partition table. Worrying about
changes that would already be involving less than O(N) work is rather
pointless in this context, IMO.

regards, tom lane