[Impala-ASF-CR] IMPALA-14910: Calcite planner: support expressions in limit clause

["Aleksandr Efimov (Code Review)" <ge...@cloudera.org>]

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 <sc...@cloudera.com>
Gerrit-Reviewer: Aleksandr Efimov <dz...@gmail.com>
Gerrit-Reviewer: Impala Public Jenkins <im...@cloudera.com>
Gerrit-Comment-Date: Sun, 23 Aug 2026 14:52:26 +0000
Gerrit-HasComments: Yes