Change in asterixdb[master]: ASTERIXDB-1581: fix subquery decorrelation.

["Till Westmann (Code Review)" <do...@asterixdb.incubator.apache.org>]

Till Westmann has posted comments on this change.

Change subject: ASTERIXDB-1581: fix subquery decorrelation.
......................................................................


Patch Set 9:

(5 comments)

Just a few comments.

https://asterix-gerrit.ics.uci.edu/#/c/1125/9/hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/metadata/IDataSource.java
File hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/metadata/IDataSource.java:

Line 36:     public boolean isScanAccessPathALeaf();
I think that we should keep the comment until the issue is fixed.


https://asterix-gerrit.ics.uci.edu/#/c/1125/9/hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/visitors/CardinalityInferenceVisitor.java
File hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/visitors/CardinalityInferenceVisitor.java:

Line 84:     private static final long ZERO_OR_ONE = 0L;
Not an issue, just a question: Why are these long values?


https://asterix-gerrit.ics.uci.edu/#/c/1125/9/hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/util/OperatorPropertiesUtil.java
File hyracks-fullstack/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/util/OperatorPropertiesUtil.java:

Line 273:         long cardinality = operator.accept(visitor, null);
inline like above?


https://asterix-gerrit.ics.uci.edu/#/c/1125/9/hyracks-fullstack/algebricks/algebricks-rewriter/src/main/java/org/apache/hyracks/algebricks/rewriter/rules/SimpleUnnestToProductRule.java
File hyracks-fullstack/algebricks/algebricks-rewriter/src/main/java/org/apache/hyracks/algebricks/rewriter/rules/SimpleUnnestToProductRule.java:

Line 60:         if (!(op2 instanceof AbstractScanOperator) && !descOrSelfIsSourceScan(op2)) {
It's not part of this change, but why do we need an instanceof here. Can't we decide this based on the operator tag?


Line 152:                 && op.getOperatorTag() != LogicalOperatorTag.UNNEST) {
It seems that the 2nd condition is always true, if the first condition is true.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia2fa4b5b836eafee1975bd1164ae7c22199a4af0
Gerrit-PatchSet: 9
Gerrit-Project: asterixdb
Gerrit-Branch: master
Gerrit-Owner: Yingyi Bu <bu...@gmail.com>
Gerrit-Reviewer: Jenkins <je...@fulliautomatix.ics.uci.edu>
Gerrit-Reviewer: Till Westmann <ti...@apache.org>
Gerrit-HasComments: Yes