[
https://issues.apache.org/jira/browse/IMPALA-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated IMPALA-7949:
--------------------------------
Description:
Consider the existing unit test:
{{ExprRewriteRulesTest.TestNormalizeBinaryPredicatesRule}}, with this SELECT
expression:
{code:sql}
cast(0 as double) = id
{code}
The existing test case simply does a "toSql" on the rewritten expression,
suppressing implicit casts, expecting:
{code:sql}
id = CAST(0 AS DOUBLE)
{code}
However, if we examine the AST itself, or render the rewritten expression
showing implicit casts, we see we get:
{code:sql}
CAST(id AS DOUBLE) = CAST(CAST(0 AS DOUBLE) AS DOUBLE)
{code}
In this particular case, the double-case it benign as the constant-folding
rule, if enabled, will remove the two casts. But, if the value were a column,
the double casts would exist in the plan sent to the, resulting in an
unnecessary extra step.
The expected behavior is the function argument type propagation would not
insert a cast if it is not needed.
Researching a bit more, it seems this is an artifact of recent changes in
{{toSql()}}. In the {{NumericLiteral}}, we always display the type as a cast.
The query specified a cast also, so the outer cast comes from the original SQL,
the inner from pushing the cast type into the numeric literal.
This is not so much a bug as it is a muddling of the semantics. There is no
reason to push the type into the numeric literal if an explicit cast exists.
was:
Consider the existing unit test:
{{ExprRewriteRulesTest.TestNormalizeBinaryPredicatesRule}}, with this SELECT
expression:
{code:sql}
cast(0 as double) = id
{code}
The existing test case simply does a "toSql" on the rewritten expression,
suppressing implicit casts, expecting:
{code:sql}
id = CAST(0 AS DOUBLE)
{code}
However, if we examine the AST itself, or render the rewritten expression
showing implicit casts, we see we get:
{code:sql}
CAST(id AS DOUBLE) = CAST(CAST(0 AS DOUBLE) AS DOUBLE)
{code}
In this particular case, the double-case it benign as the constant-folding
rule, if enabled, will remove the two casts. But, if the value were a column,
the double casts would exist in the plan sent to the, resulting in an
unnecessary extra step.
The expected behavior is the function argument type propagation would not
insert a cast if it is not needed.
> BinaryPredicate rewrite results in double cast
> ----------------------------------------------
>
> Key: IMPALA-7949
> URL: https://issues.apache.org/jira/browse/IMPALA-7949
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 3.1.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
>
> Consider the existing unit test:
> {{ExprRewriteRulesTest.TestNormalizeBinaryPredicatesRule}}, with this SELECT
> expression:
> {code:sql}
> cast(0 as double) = id
> {code}
> The existing test case simply does a "toSql" on the rewritten expression,
> suppressing implicit casts, expecting:
> {code:sql}
> id = CAST(0 AS DOUBLE)
> {code}
> However, if we examine the AST itself, or render the rewritten expression
> showing implicit casts, we see we get:
> {code:sql}
> CAST(id AS DOUBLE) = CAST(CAST(0 AS DOUBLE) AS DOUBLE)
> {code}
> In this particular case, the double-case it benign as the constant-folding
> rule, if enabled, will remove the two casts. But, if the value were a column,
> the double casts would exist in the plan sent to the, resulting in an
> unnecessary extra step.
> The expected behavior is the function argument type propagation would not
> insert a cast if it is not needed.
> Researching a bit more, it seems this is an artifact of recent changes in
> {{toSql()}}. In the {{NumericLiteral}}, we always display the type as a cast.
> The query specified a cast also, so the outer cast comes from the original
> SQL, the inner from pushing the cast type into the numeric literal.
> This is not so much a bug as it is a muddling of the semantics. There is no
> reason to push the type into the numeric literal if an explicit cast exists.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
