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:


Commit Message:

Line 7: ASTERIXDB-1487: fix the wrong plan when we purning the selective branch.
> purning -> prune

Line 10: 2. Disable the join branch pruning in case of unnestmap following 
> "unnestmap" -> "operators that do not preserve cardinality"
Yes, my current opinion aims that unnestmap will trigger index-based search, it 
will "always" introduce selection.


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) 
> Call op.getOperatorTag() once after line 202.

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

Reply via email to