You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Wang Yanlin (Jira)" <ji...@apache.org> on 2019/09/03 13:28:00 UTC

[jira] [Created] (CALCITE-3319) AssertionError for ReduceDecimalsRule

Wang Yanlin created CALCITE-3319:
------------------------------------

             Summary: AssertionError for ReduceDecimalsRule
                 Key: CALCITE-3319
                 URL: https://issues.apache.org/jira/browse/CALCITE-3319
             Project: Calcite
          Issue Type: Bug
            Reporter: Wang Yanlin


When trying to use *ReduceDecimalsRule*, I got
{code:java}
java.lang.AssertionError
	at org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:159)
	at org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:124)
	at org.apache.calcite.rex.RexCall.accept(RexCall.java:191)
	at org.apache.calcite.rex.RexProgramBuilder.add(RexProgramBuilder.java:653)
	at org.apache.calcite.rex.RexProgramBuilder.create(RexProgramBuilder.java:601)
	at org.apache.calcite.rel.rules.ReduceDecimalsRule.onMatch(ReduceDecimalsRule.java:103)
	at org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
	at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:560)
	at org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:419)
	at org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:256)
	at org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
	at org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:215)
	at org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:202)
{code}

I read the code, and found this. 

{code:java}
List<RexNode> newOperands = apply(call.getOperands());
      if (true) {
        // FIXME: Operands are now immutable. Create a new call with
        //   new operands?
        throw new AssertionError();
      }
{code}

After remove this logic, the rel below

{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[1.01E1:DOUBLE], expr#9=[15], expr#10=[+($t8, $t9)], expr#11=[>($t5, $t10)], proj#0..7=[{exprs}], $condition=[$t11])
  LogicalTableScan(table=[[scott, EMP]])
{code}

can be translated into 

{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[Reinterpret($t5)], expr#9=[CAST($t8):DOUBLE], expr#10=[1E2:DOUBLE], expr#11=[/INT($t9, $t10)], expr#12=[1.01E1:DOUBLE], expr#13=[15], expr#14=[+($t12, $t13)], expr#15=[>($t11, $t14)], proj#0..7=[{exprs}], $condition=[$t15])
  LogicalTableScan(table=[[scott, EMP]])
{code}

So is this rule not ready for use now, or we should just remove this logic?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)