On Wed, Dec 19, 2018 at 5:08 PM David Rowley
<david.rowley@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
