On Wed, Dec 19, 2018 at 5:08 PM David Rowley <david.row...@2ndquadrant.com> wrote: > With my idea for using live_parts, we'll process the partitions > looking for interleaved values on each query, after pruning takes > place. In this case, we'll see the partitions are naturally ordered. I > don't really foresee any issues with that additional processing since > it will only be a big effort when there are a large number of > partitions, and in those cases the planner already has lots of work to > do. Such processing is just a drop in the ocean when compared to path > generation for all those partitions.
I agree that partitions_are_ordered() is cheap enough in this patch that it probably doesn't matter whether we cache the result. On the other hand, that's mostly because you haven't handled the hard cases - e.g. interleaved list partitions. If you did, then it would be expensive, and it probably *would* be worth caching the result. Now maybe those hard cases aren't worth handling anyway. You also seem to be saying that since we run-time partitioning pruning might change the answer, caching the initial answer is pointless. But I think Julien has made a good argument for why that's wrong: if the initial answer is that the partitions are ordered, which will often be true, then we can skip all later checks. So I am OK with the fact that this patch doesn't choose to cache it, but I don't really buy any of your arguments for why it would be a bad idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
