Wenhai Li has posted comments on this change. Change subject: ASTERIXDB-1487: fix the wrong plan when we purning the selective branch. ......................................................................
Patch Set 13: (6 comments) https://asterix-gerrit.ics.uci.edu/#/c/1119/13//COMMIT_MSG Commit Message: Line 7: ASTERIXDB-1487: fix the wrong plan when we purning the selective branch. > purning -> prune Done Line 10: 2. Disable the join branch pruning in case of unnestmap following datasourcescan. > "unnestmap" -> "operators that do not preserve cardinality" Yes, my current opinion aims that unnestmap will trigger index-based search, it will "always" introduce selection. https://asterix-gerrit.ics.uci.edu/#/c/1119/13/asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/RemoveUnusedOneToOneEquiJoinRule.java File asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/RemoveUnusedOneToOneEquiJoinRule.java: Line 120: private int removeJoinFromInputBranch(Mutable<ILogicalOperator> opRef, int startBranch) throws AlgebricksException { > Is variable startBranch necessary? We have another issue need to be handled. For example, if we have a join subplan derived from IntroduceAccessMetholdRule especially on a inverted index. The plan will be like: In short: left branch -> join <- right branch Or in detail: datasourcescan(A) -> broadcast -> secondarySearch(B) -> primarySearch(B) -> join <- datasourceScan(A) Suppose we want to project on A, after applying this patch, we will not prune the left branch. Nevertheless, we should prune the right branch since the required project table can be derived from the left branch, even the referencing variables had been configured towards the right branch by IntroduceIndexAccessMetholdRule. We are trying to handle this case. Once we go ahead with this, the iteration from line 196 will be necessary (Yep, it is not necessary currently!). Line 137: if (liveVars.isEmpty()) { Here, in the context of IntroduceAccessMethodRule, the liveVars derived from the bottom datasourcescan is essential the same yet with a different variable label. We need talk how to .... Line 196: return removeJoinFromInputBranch(opRef, 1); > What's the purpose of the recursive call here? If the pseudo unusedJoinBranchIndex is excluded by the following SELECTIVE-exception-handler, we need to switch onto the other side if possible. Line 202: AbstractLogicalOperator op = (AbstractLogicalOperator) opRef.getValue(); > Call op.getOperatorTag() once after line 202. Done -- To view, visit https://asterix-gerrit.ics.uci.edu/1119 To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1aef69a2278853fd9f8020da6639331b367ed5ad Gerrit-PatchSet: 13 Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Owner: Wenhai Li <lwhaym...@yahoo.com> Gerrit-Reviewer: Chen Li <che...@gmail.com> Gerrit-Reviewer: Jenkins <jenk...@fulliautomatix.ics.uci.edu> Gerrit-Reviewer: Jianfeng Jia <jianfeng....@gmail.com> Gerrit-Reviewer: Taewoo Kim <wangs...@yahoo.com> Gerrit-Reviewer: Till Westmann <ti...@apache.org> Gerrit-Reviewer: Wenhai Li <lwhaym...@yahoo.com> Gerrit-Reviewer: Yingyi Bu <buyin...@gmail.com> Gerrit-Reviewer: Yingyi Bu <ying...@google.com> Gerrit-HasComments: Yes
