On Wed, Nov 6, 2019 at 1:51 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <amitlangot...@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
