On Sun, Jan 6, 2019 at 4:24 AM David Rowley <david.row...@2ndquadrant.com> wrote: > > On Thu, 20 Dec 2018 at 18:20, Julien Rouhaud <rjuju...@gmail.com> wrote: > > > > > > No, what I'm proposing is to store if the partitions are naturally > > ordered or not, *and* recheck after pruning if that property could > > have changed (so if some partitions have been pruned). So we avoid > > extra processing if we already knew that the partitions were ordered > > (possibly with the default partition pruning information), or if we > > know that the partitions are not ordered and no partition have been > > pruned. > > I see. So if the flag says "Yes", then we can skip the plan-time > check, if it says "No" and partitions were pruned, then we need to > re-check as the reason the flag says "No" might have been pruned away.
Exactly. > I guess that works, but I had imagined that the test wouldn't have > been particularly expensive. As more partitions are left unpruned then > such a test costing a bit more I thought would have been unlikely to > be measurable, but then I've not written the code yet. That's where my objection is I think. IIUC, the tests aren't not especially expensive, one reason is because the multi-value list partitioning case is out of scope. I was thinking that this flag would allow that keep this case in scope while not adding much overhead, and could still be useful with future enhancements (though optimizing some cycles with huge number of partitions is probably as you said a drop in the ocean). > Are you saying that you think this patch should have this? Or are you > happy to leave it until the next round? I'd be happy if we can handle in an efficient way ordered partitioned table scan, including multi-value list partitioning, eventually. So if that means that this optimization if not the best way to handle it, or if it's just not the best time to implement it I'm perfectly fine with it.
