[jira] [Commented] (IMPALA-7855) Inconsistent typing of original/rewritten numeric expressions

["Paul Rogers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690735#comment-16690735 ] 

Paul Rogers commented on IMPALA-7855:
-------------------------------------

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: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org