On Fri, Aug 9, 2019 at 1:17 PM Amit Langote <amitlangot...@gmail.com> wrote: > On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi > <horikyota....@gmail.com> wrote: > > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote: > > > When working on it, I realized > > > that the way RelOptInfo.partition_qual is processed is a bit > > > duplicative, so I created a separate patch to make that a bit more > > > consistent. > > > > 0001 seems reasonable. By the way, the patch doesn't touch > > get_relation_constraints(), but I suppose it can use the modified > > partition constraint qual already stored in rel->partition_qual > > in set_relation_partition_info. And we could move constifying to > > set_rlation_partition_info? > > Ah, good advice. This make partition constraint usage within the > planner quite a bit more consistent.
Hmm, oops. I think that judgement was a bit too rushed on my part. I unintentionally ended up making the partition constraint to *always* be fetched, whereas we don't need it in most cases. I've reverted that change. RelOptInfo.partition_qual is poorly named in retrospect. :( It's not set for all partitions, only those that are partitioned themselves. Attached updated patches. Thanks, Amit
v3-0001-Improve-RelOptInfo.partition_qual-usage.patch
Description: Binary data
v3-0002-Improve-constraint-exclusion-usage-in-partprune.c.patch
Description: Binary data
