[jira] [Created] (CALCITE-6651) Ignore SqlLiteral in implicit Integer type cast

["suibianwanwan (Jira)" <ji...@apache.org>]

suibianwanwan created CALCITE-6651:
--------------------------------------

             Summary: Ignore SqlLiteral in implicit Integer type cast
                 Key: CALCITE-6651
                 URL: https://issues.apache.org/jira/browse/CALCITE-6651
             Project: Calcite
          Issue Type: Bug
            Reporter: suibianwanwan
            Assignee: suibianwanwan


The integer type implicit cast for IN sub-query is supported in CALCITE-5156.

But for SqlLiteral in IN, we should not force its type cast. In the following comment, in LogicalValue, we keep the type information in RelNode
{code:java}
private RexLiteral convertLiteral(SqlLiteral sqlLiteral,
    Blackboard bb, RelDataType type) {
  RexNode literalExpr = exprConverter.convertLiteral(bb, sqlLiteral);

  if (!(literalExpr instanceof RexLiteral)) {
    assert literalExpr.isA(SqlKind.CAST);
    RexNode child = ((RexCall) literalExpr).getOperands().get(0);
    assert RexLiteral.isNullLiteral(child);

    // NOTE jvs 22-Nov-2006:  we preserve type info
    // in LogicalValues digest, so it's OK to lose it here
    return (RexLiteral) child;
  }

  //.....
}{code}
Take the following SQL as an example:
{code:java}
SELECT empno
FROM emp AS e
WHERE cast(e.empno as bigint) in (130, 131, 132, 133, 134) {code}
{code:java}
LogicalProject(EMPNO=[$0])
  LogicalJoin(condition=[=($9, $10)], joinType=[inner])
    LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EMPNO0=[CAST($0):BIGINT NOT NULL])
      LogicalTableScan(table=[[CATALOG, SALES, EMP]])
    LogicalAggregate(group=[{0}])
      LogicalValues(tuples=[[{ 130 }, { 131 }, { 132 }, { 133 }, { 134 }]]){code}
The type of the Literal is inferred from the type of the LogicalValues. However, if you cast the SqlLiteral to Integer during the validation process, it will result in the following Bad Plan. In the case of too many Values, optimizations such as RexSimplify, pullUpPredicate will consume a lot of time compared to past plans.
{code:java}
LogicalProject(EMPNO=[$0])
  LogicalJoin(condition=[=($9, $10)], joinType=[inner])
    LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EMPNO0=[CAST($0):BIGINT NOT NULL])
      LogicalTableScan(table=[[CATALOG, SALES, EMP]])
    LogicalAggregate(group=[{0}])
      LogicalUnion(all=[true])
        LogicalValues(tuples=[[{ 130 }]])
        LogicalValues(tuples=[[{ 131 }]])
        LogicalValues(tuples=[[{ 132 }]])
        LogicalValues(tuples=[[{ 133 }]])
        LogicalValues(tuples=[[{ 134 }]]) {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)