On Wed, 19 Dec 2018 at 23:25, Julien Rouhaud <rjuju...@gmail.com> wrote: > On Wed, Dec 19, 2018 at 10:51 AM David Rowley > <david.row...@2ndquadrant.com> wrote: > > The reason I'm keen to leave this alone today is that determining > > which partitions are pruned requires looking at each partition's > > RelOptInfo and checking if it's marked as a dummy rel. I'm trying to > > minimise the overhead of this patch by avoiding doing any > > per-partition processing. If we get the "live_parts" Bitmapset, then > > this becomes cheaper as Bitmapsets are fairly efficient at finding the > > next set member, even when they're large and sparsely populated. > > I see. But since for now the optimisation will only be done > considering all partitions, I still think that it's better to store a > bool flag in the PartitionDesc to describe if it's natively ordered or > not, and therefore also handle the case for > non-intervleaved-multi-datums list partitioning. It won't add much > overhead and will benefit way more cases.
I'm not really in favour of adding a flag there only to remove it again once we can more easily determine the pruned partitions. Remember the flag, because it's stored in the relation cache, must be set accounting for all partitions. As soon as we want to add smarts for pruned partitions, then the flag becomes completely useless for everything. If covering all cases in the first hit is your aim then the way to go is to add the live_parts field to RelOptInfo in this patch rather than in Amit's patch in [1]. I'd much rather add the pruned partitions smarts as part of another effort. The most likely cases to benefit from this are already covered by the current patch; range partitioned tables. [1] https://commitfest.postgresql.org/21/1778/ -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
