[
https://issues.apache.org/jira/browse/IMPALA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690699#comment-16690699
]
Paul Rogers commented on IMPALA-7855:
-------------------------------------
The implicit cast implementation appears to exacerbate the problem. We add
implicit casts where needed. But, because we later reset analysis, we remove
them. This can, due to the subtle issues described above, produce a different
outcome the second time through analysis is rewrites have been performed.
Special care must be taken when doing integrated rewrites to keep types
straight.
> Excessive type widening leads to unnecessary casts
> --------------------------------------------------
>
> 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
> 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-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
