Aleksandr Efimov has posted comments on this change. ( http://gerrit.cloudera.org:8080/24268 )
Change subject: IMPALA-14910: Calcite planner: support expressions in limit clause ...................................................................... Patch Set 3: (3 comments) Went through PS3. Three notes below, none of them blocking. http://gerrit.cloudera.org:8080/#/c/24268/3/java/calcite-planner/src/main/java/org/apache/impala/calcite/rules/ImpalaSortSimplifyRule.java File java/calcite-planner/src/main/java/org/apache/impala/calcite/rules/ImpalaSortSimplifyRule.java: http://gerrit.cloudera.org:8080/#/c/24268/3/java/calcite-planner/src/main/java/org/apache/impala/calcite/rules/ImpalaSortSimplifyRule.java@50 PS3, Line 50: if (sort.fetch instanceof RexLiteral && sort.offset instanceof RexLiteral) { Small thing: for the common shape the offset is null rather than a literal, so "limit 10" with no OFFSET does not take this early exit and goes through the reduce path anyway - "(sort.fetch == null || sort.fetch instanceof RexLiteral) && (sort.offset == null || sort.offset instanceof RexLiteral)" would catch it. Also, "changed" on line 61 looks unused. http://gerrit.cloudera.org:8080/#/c/24268/3/java/calcite-planner/src/main/java/org/apache/impala/calcite/service/ImpalaSqlValidatorImpl.java File java/calcite-planner/src/main/java/org/apache/impala/calcite/service/ImpalaSqlValidatorImpl.java: http://gerrit.cloudera.org:8080/#/c/24268/3/java/calcite-planner/src/main/java/org/apache/impala/calcite/service/ImpalaSqlValidatorImpl.java@193 PS3, Line 193: // Offset and limit expressions will always have a BIGINT type. Could the comment say what reads this type? I followed the fetch through Blackboard.convertExpression() into StandardConvertletTable, which derives the RexCall type from rexBuilder.deriveReturnType(), so I could not see where the override lands - and knowing that would also answer what happens to a non-integer expression. The original planner rejects "limit 1 + 0.5" with "LIMIT expression must be an integer type but is 'DECIMAL(2,1)': 1 + 0.5" (Expr.java:1925), and I could not tell whether forcing BIGINT here makes the Calcite side accept it and truncate instead. http://gerrit.cloudera.org:8080/#/c/24268/3/testdata/workloads/functional-query/queries/QueryTest/calcite.test File testdata/workloads/functional-query/queries/QueryTest/calcite.test: http://gerrit.cloudera.org:8080/#/c/24268/3/testdata/workloads/functional-query/queries/QueryTest/calcite.test@1380 PS3, Line 1380: select id from functional.alltypes order by id limit 1 + 1 Would you mind adding a couple more cases here? The validator change covers OFFSET as well, but nothing exercises "offset 1 + 1". And the parser now accepts shapes that used to be parse errors, where the original planner has its own messages: "limit -1" gives "LIMIT must be a non-negative integer: -1 = -1" and "limit id" gives "LIMIT expression must be a constant expression: id" (Expr.java:1976 and :1917). A CATCH case for each would pin down what the Calcite path does with them. -- To view, visit http://gerrit.cloudera.org:8080/24268 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Ic01a0144671485156654e7685d0d5816fa743f9d Gerrit-Change-Number: 24268 Gerrit-PatchSet: 3 Gerrit-Owner: Steve Carlin <[email protected]> Gerrit-Reviewer: Aleksandr Efimov <[email protected]> Gerrit-Reviewer: Impala Public Jenkins <[email protected]> Gerrit-Comment-Date: Sun, 23 Aug 2026 14:52:26 +0000 Gerrit-HasComments: Yes
