On Wed, Nov 6, 2019 at 1:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <amitlangote09@gmail.com> writes:
> > I have been thinking maybe add_child_rel_equivalences() doesn't need
> > to translate EC members that reference multiple appendrels, because
> > there top_parent_relids is always a singleton set, whereas em_relids
> > of such expressions is not? Those half-translated expressions are
> > useless, only adding to the overhead of scanning ec_members. I'm
> > thinking that we should apply this diff:
> > - if (bms_overlap(cur_em->em_relids, top_parent_relids))
> > + if (bms_is_subset(cur_em->em_relids, top_parent_relids))
>
> Meh, I'm not really convinced. The case where this would be relevant
> is an EC generated from something like "WHERE (a.x + b.y) = c.z"
> where "a" is partitioned. It's possible that we'd never have a use
> for a sort key corresponding to "a_child.x + b.y", but I think that's
> not obvious, and probably short-sighted. Anyway such EC members are
> pretty rare in the first place, so we're not going to win much
> performance by trying to optimize them.
OK.
> Anyway, I've pushed the fix for Justin's problem to v12 and HEAD.
> The problem with poor planning of multiway joins that you mentioned
> in the other thread remains open, but I imagine the patches you
> posted there are going to need rebasing over this commit, so I
> set that CF entry to Waiting On Author.
Thank you. I will send rebased patches on that thread.
Regards,
Amit
