rubenada commented on code in PR #4515:
URL: https://github.com/apache/calcite/pull/4515#discussion_r2313219065
##########
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:
Maybe I'm missing something, but is this a valid example of the rule being
applied? In case of a RIGHT JOIN and the sort collation not being fields from
the RHS is the sort really pushed down?
That does not seem to be the case on `planner.iq` example (we dont have an
`EnumerableLimit(fetch=[12])` inside the join's RHS
--
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]
