Dmitry Lychagin has posted comments on this change.

Change subject: [ASTERIXDB-1972][COMP][RT][TX] index-only plan
......................................................................


Patch Set 43:

(4 comments)

https://asterix-gerrit.ics.uci.edu/#/c/1866/43/asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/am/AccessMethodUtils.java
File 
asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/am/AccessMethodUtils.java:

Line 2236:                                         tmpValFieldType = 
probeRecordType.getFieldType(fieldName);
ARecordType.getFieldType() does not throw exception, so what are we catching 
here? Can we remove try-catch and CANNOT_GET_FIELD_TYPE_FOR_FIELD_NAME error 
code.


https://asterix-gerrit.ics.uci.edu/#/c/1866/43/asterixdb/asterix-common/src/main/java/org/apache/asterix/common/exceptions/ErrorCode.java
File 
asterixdb/asterix-common/src/main/java/org/apache/asterix/common/exceptions/ErrorCode.java:

Line 146:     public static final int NO_RETAIN_INPUT_IN_LEFT_OUTER_JOIN = 1067;
NO_RETAIN_INPUT_IN_LEFT_OUTER_JOIN is not used. Let's remove it


https://asterix-gerrit.ics.uci.edu/#/c/1866/43/hyracks-fullstack/algebricks/algebricks-rewriter/src/main/java/org/apache/hyracks/algebricks/rewriter/rules/IntroduceProjectsRule.java
File 
hyracks-fullstack/algebricks/algebricks-rewriter/src/main/java/org/apache/hyracks/algebricks/rewriter/rules/IntroduceProjectsRule.java:

Line 199:                     eliminateProject = 
canEliminateProjectBelowUnion(unionOp, projectOp, parentInputIndex);
parentInputIndex will be incorrect if we have UNIONALL-> EXCHANGE -> PROJECT, 
because it'll be PROJECT's input index in the EXCHANGE, but should be 
EXCHANGE's index in the UNIONALL. 
I think there are two approaches to fixing this.
1) in addition to parentOp, parentIndex pass grandparentOp, grandparentIndex to 
introduceProjects(). Remove afterProjectRefs because it won't be necessary. 
Also check that parent is EXCHANGE, just to be safe. 

2) alternatively may be we could explore if we can remove the check for 
UNIONALL at this point and let PROJECT be eliminated if projectVars == 
liveVars, but then add a special case in this rule which looks for UNIONALL and 
if its branch variables are out of order then introduce PROJECT for that branch 
to fix variable order. I think it might be better than (1). What do you think?


https://asterix-gerrit.ics.uci.edu/#/c/1866/43/hyracks-fullstack/hyracks/hyracks-api/src/main/java/org/apache/hyracks/api/exceptions/ErrorCode.java
File 
hyracks-fullstack/hyracks/hyracks-api/src/main/java/org/apache/hyracks/api/exceptions/ErrorCode.java:

Line 144:     public static final int 
FULLTEXT_ONLY_EXECUTABLE_FOR_STRING_OR_LIST = 108;
FULLTEXT_ONLY_EXECUTABLE_FOR_STRING_OR_LIST is not used. Let's remove it


-- 
To view, visit https://asterix-gerrit.ics.uci.edu/1866
To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ifd5c9ab1cf2e4bedb7d8db582441919875e74d51
Gerrit-PatchSet: 43
Gerrit-Project: asterixdb
Gerrit-Branch: master
Gerrit-Owner: Taewoo Kim <[email protected]>
Gerrit-Reviewer: Anon. E. Moose #1000171
Gerrit-Reviewer: Dmitry Lychagin <[email protected]>
Gerrit-Reviewer: Ildar Absalyamov <[email protected]>
Gerrit-Reviewer: Jenkins <[email protected]>
Gerrit-Reviewer: Taewoo Kim <[email protected]>
Gerrit-Reviewer: Till Westmann <[email protected]>
Gerrit-Reviewer: Yingyi Bu <[email protected]>
Gerrit-HasComments: Yes

Reply via email to