Jianfeng Jia has posted comments on this change. Change subject: Intersect the 2ndary indexes before primary search ......................................................................
Patch Set 2: (9 comments) https://asterix-gerrit.ics.uci.edu/#/c/577/2/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/IntersectOperator.java File algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/IntersectOperator.java: Line 92: //TODO introduce an UNION type if possible > Why do we need a UNION type? Removed. Line 93: IVariableTypeEnvironment env = createPropagatingAllInputsTypeEnvironment(ctx); > Why do we need to propagate all input types? Changed to NonPropagatingTypeEnvironment Line 108: public List<LogicalVariable> getInputVariables(int i) { > i->inputIndex Done Line 112: private void checkIfTwoTypeEnvIsEqual(IVariableTypeEnvironment expected, List<LogicalVariable> expectedVariables, > checkIfTwoTypeEnvIsEqual --> checkTypeConsistency Done Line 118: AlgebricksConfig.ALGEBRICKS_LOGGER.warning("Type of two variables are not equal." + > Throw an exception for that case? Since we enable the runtime type casting, in the compilation time we should tolerate such inconsistency. I think a better solution is to have a type hierarchy logic module to decide if two types can be compared. https://asterix-gerrit.ics.uci.edu/#/c/577/2/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/visitors/LogicalOperatorDeepCopyWithNewVariablesVisitor.java File algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/logical/visitors/LogicalOperatorDeepCopyWithNewVariablesVisitor.java: Line 434: List<List<LogicalVariable>> liveVarsInInputs = getLiveVarsInInputs(op); > getLiveVarsInInputs --> visitInputs Done https://asterix-gerrit.ics.uci.edu/#/c/577/2/algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/physical/IntersectPOperator.java File algebricks/algebricks-core/src/main/java/org/apache/hyracks/algebricks/core/algebra/operators/physical/IntersectPOperator.java: Line 75: // when should we care about the parent requirement? > This method is to express the required properties for its children. Done Line 89: List<ILocalStructuralProperty> propsLocal = op.getDeliveredPhysicalProperties().getLocalProperties(); > The property of the first child is based on its available variables. Theref I'm not following the comment. Could you give me some more hints or examples? https://asterix-gerrit.ics.uci.edu/#/c/577/2/hyracks/hyracks-dataflow-common/src/main/java/org/apache/hyracks/dataflow/common/comm/io/FrameFixedFieldAppender.java File hyracks/hyracks-dataflow-common/src/main/java/org/apache/hyracks/dataflow/common/comm/io/FrameFixedFieldAppender.java: Line 30: public class FrameFixedFieldAppender extends AbstractFrameAppender implements IFrameFieldAppender { > Why need to change this one? Done -- To view, visit https://asterix-gerrit.ics.uci.edu/577 To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic16c67c529ca19d8b1a5439ddef22760945fd0d7 Gerrit-PatchSet: 2 Gerrit-Project: hyracks Gerrit-Branch: master Gerrit-Owner: Jianfeng Jia <[email protected]> Gerrit-Reviewer: Jenkins <[email protected]> Gerrit-Reviewer: Jianfeng Jia <[email protected]> Gerrit-Reviewer: Taewoo Kim <[email protected]> Gerrit-Reviewer: Yingyi Bu <[email protected]> Gerrit-Reviewer: Yingyi Bu <[email protected]> Gerrit-HasComments: Yes
