On Fri, Aug 9, 2019 at 1:17 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> <horikyota.ntt@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