Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers