Re: Future directions for inheritance-hierarchy statistics - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Future directions for inheritance-hierarchy statistics
Date
Msg-id 22764.1426687604@sss.pgh.pa.us
Whole thread Raw
In response to Re: Future directions for inheritance-hierarchy statistics  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Left lateral join with for update and skip locked
Next
From: Thom Brown
Date:
Subject: Re: GSoC 2015 - mentors, students and admins.