I see. I think this is related to isomorphism. As the comment says, we need to find a way to resolve "complication of figuring out whether the firstOp in an equivalence class is within a subplan".
Best, Taewoo On Sat, Oct 19, 2019 at 12:40 PM Wail Alkowaileet <[email protected]> wrote: > Hi Taewoo, > > I might be got confused by the comment. But still did not get why it > is commented? > Sub-plans are missing a few optimizations. For example after > uncommenting this code and fixing InlineSingleReferenceVariableRule > for sub-plans we get: > > Before: > > ........ > subplan { > aggregate [$$10] <- [listify($$9)] > -- AGGREGATE |LOCAL| > assign [$$9] <- [eq($$22, "Tom")] > -- ASSIGN |LOCAL| > assign [$$22] <- > [$$30.getField("firstName")] > -- ASSIGN |LOCAL| > assign [$$30] <- > [$$29.getField("name")] > -- ASSIGN |LOCAL| > assign [$$29] <- > [$$x.getField("names")] > -- ASSIGN |LOCAL| > select (eq($$21, "1")) > -- STREAM_SELECT |LOCAL| > nested tuple source > -- NESTED_TUPLE_SOURCE |LOCAL| > } > -- SUBPLAN |PARTITIONED| > project ([$$x, $$21, $$25]) > -- STREAM_PROJECT |PARTITIONED| > assign [$$21, $$25] <- > [$$28.getField("count"), $$28.getField("name")] > -- ASSIGN |PARTITIONED| > assign [$$28] <- [$$x.getField("names")] > -- ASSIGN |PARTITIONED| > ........ > > After: > > ........ > subplan { > aggregate [$$10] <- [listify($$9)] > -- AGGREGATE |LOCAL| > assign [$$9] <- > [eq($$26.getField("firstName"), "Tom")] > -- ASSIGN |LOCAL| > select (eq($$22, "1")) > -- STREAM_SELECT |LOCAL| > nested tuple source > -- NESTED_TUPLE_SOURCE |LOCAL| > } > -- SUBPLAN |PARTITIONED| > project ([$$x, $$22, $$26]) > -- STREAM_PROJECT |PARTITIONED| > assign [$$26, $$22] <- [$$20.getField("name"), > $$20.getField("count")] > -- ASSIGN |PARTITIONED| > assign [$$20] <- [$$x.getField("names")] > -- ASSIGN |PARTITIONED| > ........ > <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, > Oct 19, 2019 at 11:15 AM Taewoo Kim <[email protected]> > wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px > 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: > 1ex;">Hi Wail,<br> > <br> > I think that's what the comment implies (I could not produce an > expression<br> > where it used in a sub-plan and not visible to upper operators?). If > you<br> > want to make it happen, a workaround might be introducing a project<br> > operator within the subplan of the subplan operator? Actually, if a<br> > variable is not used, isn't project operator supposed to remove them<br> > automatically by IntroduceProjectsRule?<br> > <br> > Best,<br> > Taewoo<br> > <br> > <br> > On Sat, Oct 19, 2019 at 10:05 AM Wail Alkowaileet <<a > href="mailto:[email protected]"; > target="_blank">[email protected]</a>><br> > wrote:<br> > <br> > > Hi Dev,<br> > ><br> > > I'm not sure about the commented code in [1]. I could not produce > an<br> > > expression where it used in a sub-plan and not visible to upper > operators?<br> > > Also, all SQL++ runtime integration tests seem to work just fine.<br> > ><br> > ><br> > > [1] ExtractCommonExpressionsRule.j<wbr>ava#L192<br> > > <<br> > > <a href=" > https://github.com/apache/asterixdb/blob/f2c18aa9646238ab2487ce3a964edfe3e61dd6e1/hyracks-fullstack/algebricks/algebricks-rewriter/src/main/java/org/apache/hyracks/algebricks/rewriter/rules/ExtractCommonExpressionsRule.java#L192 > " > rel="noreferrer" > target="_blank">https://github.com/apache/aste > <wbr>rixdb/blob/f2c18aa9646238ab248<wbr>7ce3a964edfe3e61dd6e1/hyracks-<wbr>fullstack/algebricks/<wbr>algebricks-rewriter/src/main/<wbr>java/org/apache/hyracks/<wbr>algebricks/rewriter/rules/Extr<wbr>actCommonExpressionsRule.java#<wbr>L192</a><br> > > ><br> > ><br> > > --<br> > ><br> > > *Regards,*<br> > > Wail Alkowaileet<br> > ><br> > </blockquote></div><br clear="all"><div><br></div>-- <br><div > dir="ltr" class="gmail_signature"><br><b>Regards,</b><br>Wail > Alkowaileet<br></div> >
