On Wed, 6 Mar 2019 at 07:17, Robert Haas <robertmh...@gmail.com> wrote: > > 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.
I admit that I didn't understand the idea of the flag at the time, having failed to see the point of it since if partitions are plan-time pruned then I had thought the flag would be useless. However, as Julien explained, it would be a flag of "Yes" means "Yes", okay to do ordered scans, and "No" means "Recheck if there are pruned partitions using only the non-pruned ones". That seems fine and very sane to me now that I understand it. FWIW, my moment of realisation came in [1]. However, my thoughts are that adding new flags and the live_parts field in RelOptInfo raise the bar a bit for this patch. There's already quite a number of partition-related fields in RelOptInfo. Understanding what each of those does is not trivial, so I figured that this patch would be much easier to consider if I skipped that part for the first cut version. I feared a lot of instability of what fields exist from Amit's planner improvement patches and I didn't want to deal with dependencies from WIP. I had to deal with that last year on run-time pruning and it turned out not to be fun. > 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. OK, good. I agree. For the record; I want to steer clear of the flag in this first cut version, especially so now given what time it is. [1] https://www.postgresql.org/message-id/cakjs1f_r51oapsn1oc4i36d7vznnihnk+1widfg0qrvb_eo...@mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
