[
https://issues.apache.org/jira/browse/CALCITE-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635490#comment-17635490
]
Ian Bertolacci commented on CALCITE-5387:
-----------------------------------------
[~zabetak] I believe that it is because that there are two type-checking
systems going on.
When the original plan is is being constructed and the join condition is being
built, the type-checking system is the actual SqlOperator's type checker
system. The {{`EQUALS`}} operators sees {{`$8 : BigInt`}} and {{`$2 : BigInt
not null`}}, and says "this is ok, because these are comparable and at the very
least coerce-able to each other"
When the expression is being *copied*, basically it seems like the expression
{{`>($0, 10)`}} is being completely copied, but the index of {{`$0`}} is
changed to 1 (to point to C2).
But nothing else has changed, most importantly, the type of {{`$1`}} (I think,
I'll double check) which is still {{`BigInt not nullable`}} from the original
expression.
Then the RelOptUtil comes along and asks: "Does the type of {{`$1`}} (which is
{{`BigInt not null`}}) match field 1 of {{`9:QueryTableScan`}} (which is
{{`BigInt`}})"
The answer is no, and so the exception is thrown.
So I think that the fundamental problem is that the expression is not being
fully rebuilt with the appropriate types of the inputs.
> type-mismatch on nullability in JOIN_PUSH_TRANSITIVE_PREDICATES
> ---------------------------------------------------------------
>
> Key: CALCITE-5387
> URL: https://issues.apache.org/jira/browse/CALCITE-5387
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.30.0
> Reporter: Ian Bertolacci
> Priority: Major
>
> If the the join operands have the same core type, but different nulabilities,
> then an exception is thrown during CoreRules.JOIN_PUSH_TRANSITIVE_PREDICATES
> because the types "mismatch".
> For example:
> {{`select * from Query.Test as t join (select * from QUERY.JoinTable as j
> where j.ID > 10) as j on j.ID = t.C2`}}
> Here, ID is {{`BIGINT NOT NULL`}} and C2 is {{`BIGINT`}}
> Initial plan:
> {code}
> 14:LogicalProject(ID=[$0], C1=[$1], C2=[$2], C3=[$3], C4=[$4], C5=[$5],
> C6=[$6], C7=[$7], ID0=[$8], C10=[$9])
> 13:LogicalJoin(condition=[=($8, $2)], joinType=[inner])
> 9:QueryTableScan(table=[[QUERY, Test]], fields=[[0, 1, 2, 3, 4, 5, 6, 7]])
> 12:LogicalProject(ID=[$0], C1=[$1])
> 11:LogicalFilter(condition=[>($0, 10)])
> 10:QueryTableScan(table=[[QUERY, JoinTable]], fields=[[0, 1]])
> {code}
> Exception and stack-trace:
> {code}
> type mismatch:
> ref:
> BIGINT NOT NULL
> input:
> BIGINT
> java.lang.AssertionError: type mismatch:
> ref:
> BIGINT NOT NULL
> input:
> BIGINT
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Filter.isValid(Filter.java:125)
> at org.apache.calcite.rel.core.Filter.<init>(Filter.java:81)
> at
> org.apache.calcite.rel.logical.LogicalFilter.<init>(LogicalFilter.java:69)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:114)
> at
> org.apache.calcite.rel.core.RelFactories$FilterFactoryImpl.createFilter(RelFactories.java:345)
> at org.apache.calcite.tools.RelBuilder.filter(RelBuilder.java:1737)
> at org.apache.calcite.tools.RelBuilder.filter(RelBuilder.java:1697)
> at
> org.apache.calcite.rel.rules.JoinPushTransitivePredicatesRule.onMatch(JoinPushTransitivePredicatesRule.java:88)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeRuleCollection(HepPlanner.java:286)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleCollection$State.execute(HepInstruction.java:105)
> at
> org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
> at
> com.google.common.collect.ImmutableList.forEach(ImmutableList.java:406)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
> at
> org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191)
> {code}
> My thinking is that checking if the two types are equal is not meaningful.
> Instead what should happen is that the whole expression is type checked from
> scratch using the new operand type.
> Even if the new and original operant types are different (in any ways) so
> long as the expression successfully type-checks, then the expression is safe
> to use.
> Or maybe I'm just using the rule wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
