[
https://issues.apache.org/jira/browse/CALCITE-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019979#comment-18019979
]
Zhen Chen commented on CALCITE-7181:
------------------------------------
Hi [~julianhyde]
Let me try to understand your suggestion, and please correct me if I'm wrong.
You mentioned using BigDecimal to handle Sort.fetch and Sort.offset ,
which I think would work fine after generating the RelNode . My reasoning for
using long was to align with BIGINT , since most databases typically use
BIGINT as the SQL type for Sort.fetch and Sort.offset . At the SQL level,
the largest integer type available is BIGINT , so my idea was to use long in
Java to match it.
In CALCITE-7156, it was mentioned that the current linq4j runtime relies on
List for computation, meaning it can't even cover the full range of BIGINT .
Therefore, the approach taken in CALCITE-7156 was to standardize some types as
BIGINT at the planning stage while only supporting INT at runtime.
If you agree with this approach, then I understand that there's no need to use
BigDecimal at the Java level. Have I missed anything? Looking forward to your
reply!
> FETCH in SortRemoveRedundantRule do not support BIGINT
> ------------------------------------------------------
>
> Key: CALCITE-7181
> URL: https://issues.apache.org/jira/browse/CALCITE-7181
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.40.0
> Reporter: Zhen Chen
> Assignee: Zhen Chen
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.41.0
>
>
> This case can not work.
> {code:java}
> @Test void testSortRemoveWhenInputValuesMaxRowCntLessOrEqualLimitFetch2() {
> final String sql = "select * from\n"
> + "(VALUES 1,2,3,4,5,6) as t1 limit 3000000000";
> sql(sql)
> .withRule(CoreRules.SORT_REMOVE_REDUNDANT)
> .check();
> }
> {code}
> {code:java}
> Integer overflow: 3000000000 is out of range for INT
> java.lang.ArithmeticException: Integer overflow: 3000000000 is out of range
> for INT
> at org.apache.calcite.rex.RexLiteral.intValue(RexLiteral.java:1280)
> at
> org.apache.calcite.rel.rules.SortRemoveRedundantRule.getRowCountThreshold(SortRemoveRedundantRule.java:133)
> at
> org.apache.calcite.rel.rules.SortRemoveRedundantRule.onMatch(SortRemoveRedundantRule.java:117)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:350)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:527)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:419)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeRuleInstance(HepPlanner.java:242)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance$State.execute(HepInstruction.java:178)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
