Hi All, As an experiment, I switched the order of inputs to EnumerableDefaults::join_ during the implementation stage of EnumerableJoin if the Join type is Inner. Since there will be no need to generate nulls on either side, I would assume that the choice of the side being built and the side being probed would not make a difference in the result.
However, I see multiple test failures. On further investigation, I saw that the failures are coming due to change in order of the columns and due to the fact that a different column is being built now. For e.g., testInnerJoinValues fails with the following stack: Caused by: java.lang.NumberFormatException: For input string: "SameName" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Integer.parseInt(Integer.java:652) at java.base/java.lang.Integer.parseInt(Integer.java:770) at org.apache.calcite.runtime.SqlFunctions.toInt(SqlFunctions.java:1571) at org.apache.calcite.runtime.SqlFunctions.toInt(SqlFunctions.java:1581) at Baz$4$1.moveNext(Unknown Source) at org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:825) at org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:761) at org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) at Baz.bind(Unknown Source) at org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:365) at org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:301) at org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:559) at org.apache.calcite.jdbc.Calcite Can someone please advise? The current code is at: https://github.com/atris/calcite/tree/join_side_temp Regards, Atri
