[
https://issues.apache.org/jira/browse/CALCITE-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971425#comment-15971425
]
Julian Hyde commented on CALCITE-1738:
--------------------------------------
In the ideal case, all casts of literals would be flattened to literals, so
this code would not be needed. So clearly we are not dealing with the ideal
case. So let's figure out the exact circumstances where a cast of a literal
would remain.
One possibility is a cast of a date string (e.g. '2010-01-01') to a timestamp.
That's not a "pure" cast because it needs a timezone from the executor.
Another possibility is a cast of a non-nullable timestamp literal to a nullable
timestamp.
Based on what you've said, the latter seems more likely. I think you should
narrow your code down to the exact kind of cast (e.g. one that converts a
timestamp to a timestamp and changes nullability but does not change data
type). Otherwise there's too much risk of unintended consequences.
> Support CAST of literal values in filters pushed to Druid
> ---------------------------------------------------------
>
> Key: CALCITE-1738
> URL: https://issues.apache.org/jira/browse/CALCITE-1738
> Project: Calcite
> Issue Type: Improvement
> Components: druid
> Reporter: Remus Rusanu
> Assignee: Remus Rusanu
>
> Because HIVE-16027 forced an implicit CAST on queries like {{WHERE
> <timestampcolumn> IN ('<literal', '<literal>')}}, IN, BETEWEEN and other
> filters are no longer pushed down to Druid. In this call stack:
> {noformat}
> org.apache.calcite.adapter.druid.DruidDateTimeUtils.literalValue(DruidDateTimeUtils.java:246)
> at
> org.apache.calcite.adapter.druid.DruidDateTimeUtils.leafToRanges(DruidDateTimeUtils.java:227)
> at
> org.apache.calcite.adapter.druid.DruidDateTimeUtils.extractRanges(DruidDateTimeUtils.java:120)
> at
> org.apache.calcite.adapter.druid.DruidDateTimeUtils.createInterval(DruidDateTimeUtils.java:65)
> at
> org.apache.calcite.adapter.druid.DruidRules$DruidFilterRule.onMatch(DruidRules.java:186)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:317)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:506)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:385)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:125)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:197)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner$CalcitePlannerAction.hepPlan(CalcitePlanner.java:1790)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner$CalcitePlannerAction.apply(CalcitePlanner.java:1518)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner$CalcitePlannerAction.apply(CalcitePlanner.java:1265)
> at org.apache.calcite.tools.Frameworks$1.apply(Frameworks.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:1043)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:149)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:106)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner.logicalPlan(CalcitePlanner.java:1073)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner.getOptimizedAST(CalcitePlanner.java:1089)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner.genOPTree(CalcitePlanner.java:368)
> at
> org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.analyzeInternal(SemanticAnalyzer.java:11119)
> at
> org.apache.hadoop.hive.ql.parse.CalcitePlanner.analyzeInternal(CalcitePlanner.java:290)
> at
> org.apache.hadoop.hive.ql.parse.BaseSemanticAnalyzer.analyze(BaseSemanticAnalyzer.java:258)
> {noformat}
> the literalValue only knows how to handle {{RexLiteral}} case. Because of the
> CAST, the node is a {{RexCall}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
