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 6531.1426605968@sss.pgh.pa.us
Whole thread Raw
In response to Re: Future directions for inheritance-hierarchy statistics  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Future directions for inheritance-hierarchy statistics
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> For some reason, I didn't get Tom's email, only this reply.
>> On 2015/03/17 5:18, Tom Lane wrote:
>>> 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.)

> That's a pretty big drawback.  I'm not sure whether it's big enough to
> sink the whole idea, but we really need to make planning time on large
> inheritance trees cheaper, not more expensive.

Ah, but note the point about how there's no added cost for partitions that
are removed by constraint exclusion.  That should mean that in practical
use it's not a huge problem.  (If you're going to scan K partitions, you
should not be surprised that planning time is O(K).  It will be anyway
thanks to other things such as index selection.)

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Next
From: Fabien COELHO
Date:
Subject: Re: PATCH: pgbench - merging transaction logs