Yingyi Bu has posted comments on this change. Change subject: ASTERIXDB-1581: fix subquery decorrelation. ......................................................................
Patch Set 9: (5 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. Done 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? Hopefully the visitor can be enhanced to do "real" cardinality estimation where a long value is needed... However, currently it only does simple "symbolic executions"... I can turn this down to a byte. 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? Done 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 Done Line 152: && op.getOperatorTag() != LogicalOperatorTag.UNNEST) { > It seems that the 2nd condition is always true, if the first condition is t Done -- 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 <[email protected]> Gerrit-Reviewer: Jenkins <[email protected]> Gerrit-Reviewer: Till Westmann <[email protected]> Gerrit-Reviewer: Yingyi Bu <[email protected]> Gerrit-HasComments: Yes
