rubenada commented on code in PR #4515:
URL: https://github.com/apache/calcite/pull/4515#discussion_r2313306328
##########
core/src/main/java/org/apache/calcite/rel/rules/SortJoinTransposeRule.java:
##########
@@ -23,25 +23,53 @@
import org.apache.calcite.rel.RelFieldCollation;
import org.apache.calcite.rel.RelNode;
import org.apache.calcite.rel.core.Join;
-import org.apache.calcite.rel.core.JoinInfo;
import org.apache.calcite.rel.core.JoinRelType;
import org.apache.calcite.rel.core.Sort;
import org.apache.calcite.rel.logical.LogicalJoin;
import org.apache.calcite.rel.logical.LogicalSort;
import org.apache.calcite.rel.metadata.RelMdUtil;
import org.apache.calcite.rel.metadata.RelMetadataQuery;
+import org.apache.calcite.rex.RexBuilder;
import org.apache.calcite.rex.RexDynamicParam;
+import org.apache.calcite.rex.RexLiteral;
+import org.apache.calcite.rex.RexNode;
import org.apache.calcite.tools.RelBuilderFactory;
+import org.checkerframework.checker.nullness.qual.Nullable;
import org.immutables.value.Value;
+import java.math.BigDecimal;
+
/**
- * Planner rule that pushes a {@link org.apache.calcite.rel.core.Sort} past a
- * {@link org.apache.calcite.rel.core.Join}.
+ * Planner rule that pushes a {@link Sort} past a {@link Join}.
+ *
+ * <p>This rule applies to left/right outer joins, and only pushes the sort if
its keys are
+ * entirely from one input. It will not fire if the sort uses dynamic
parameters or the input
+ * is already sorted and limited. However, an extension for full outer joins
for this rule could
+ * be envisioned.
*
- * <p>At the moment, we only consider left/right outer joins.
- * However, an extension for full outer joins for this rule could be
envisioned.
- * Special attention should be paid to null values for correctness issues.
+ * <p>For example, given the SQL:
+ * <pre>
+ * select d.deptno, empno from sales.dept d
+ * right join sales.emp e using (deptno) limit 10 offset 2
+ * </pre>
+ * The initial plan:
+ * <pre>
+ * LogicalProject(DEPTNO=[$0], EMPNO=[$2])
+ * LogicalSort(offset=[2], fetch=[10])
+ * LogicalJoin(condition=[=($0, $9)], joinType=[right])
+ * LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
+ * LogicalTableScan(table=[[CATALOG, SALES, EMP]])
+ * </pre>
+ * After applying this rule:
+ * <pre>
+ * LogicalProject(DEPTNO=[$0], EMPNO=[$2])
+ * LogicalSort(offset=[2], fetch=[10])
+ * LogicalJoin(condition=[=($0, $9)], joinType=[right])
+ * LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
+ * LogicalSort(fetch=[12])
Review Comment:
I haven't verified but IIANM in this case the rule is not really applied
because the check `checkInputForCollationAndLimit` returns true (the RHS is
already "sorted" because the sort collation is empty, so the rule bails out).
Maybe this example (and the corresponding test on `planner.iq`) would be
more clear if e.g. we add an `ORDER BY ename` ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
