[
https://issues.apache.org/jira/browse/IMPALA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690735#comment-16690735
]
Paul Rogers edited comment on IMPALA-7855 at 11/18/18 5:57 AM:
---------------------------------------------------------------
See IMPALA-7865 for how this same issue plays out in the time dimension,
resulting in unstable behavior.
was (Author: paul.rogers):
The code in question is in {{TypesUtils.getArithmeticResultType()}}:
{code:java}
// If one of the types is null, use the compatible type without
promotion.
// Otherwise, promote the compatible type to the next higher resolution
type,
// to ensure that that a <op> b won't overflow/underflow.
{code}
This means that {{1 + 1 + 1 + 1}} = {{(((1 + (1 + (1 + 1)))}}, which means we
apply the above twice:
* {{TINYINT}} + {{TINYINT}} --> {{SMALLINT}}
* {{SMALLINT}} + {{TINYINT}} --> {{INT}}
* {{INT}} + {{TINYINT}} --> {{BIGINT}}
So, we need a {{BIGINT}} to hold the value of 4.
But, once we do constant folding, the result type is {{TINYINT}}, but we need
to cast it to {{BIGINT}} to be consistent with the (bogus) earlier type
analysis.
Seems we need to do the constant folding before we do type promotion. But, even
that won't cause the same silly problems if we added for {{TINYINT}} columns
and ended up with a {{BIGINT}} result.
> Inconsistent typing of original/rewritten numeric expressions
> -------------------------------------------------------------
>
> Key: IMPALA-7855
> URL: https://issues.apache.org/jira/browse/IMPALA-7855
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
>
> When writing unit tests, created the following query:
> {code:sql}
> with
> query1 (a, b) as (
> select 1 + 1 + id, 2 + 3 + int_col from functional.alltypestiny)
> insert into functional.alltypestiny (id, int_col)
> partition (month = 5, year = 2018)
> select * from query1
> {code}
> The above fails with the following error:
> {noformat}
> ERROR: AnalysisException: Possible loss of precision for target table
> 'functional.alltypestiny'.
> Expression 'query1.a' (type: BIGINT) would need to be cast to INT for column
> 'id'
> {noformat}
> The following does work (for planning, may not actually execute):
> {code:sql}
> with
> query1 (a, b) as (
> select
> cast(1 + 1 + id as int),
> cast(2 + 3 + int_col as int)
> from functional.alltypestiny)
> insert into functional.alltypestiny (id, int_col)
> partition (month = 5, year = 2018)
> select * from query1
> {code}
> What this says is the the planner selected type {{BIGINT}} for the
> (rewritten) expression {{2 + id}} where {{id}} is of type {{INT}}. {{BIGINT}}
> is a conservative guess: adding 2 to the largest {{INT}} could overflow and
> require a {{BIGINT}}.
> Yet, for such a simple case, such aggressive type promotion may be overly
> cautious.
> To verify that this is an issue, let's try something similar with Postgres to
> see if it is as aggressive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
