[
https://issues.apache.org/jira/browse/IMPALA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690748#comment-16690748
]
Paul Rogers commented on IMPALA-7855:
-------------------------------------
Turns out type propagation is unstable over time: the same problem as above,
but plays out over the life of analysis.
* Start with {{tinyint_col + 1}}
* Analyze in {{SelectStmt.analyze()}} to\\ {{(tinyint_col: TINYINT) + (1:
TINYINT)): SMALLINT}}
* Perform alias substitution and rewrite to\\ {{((tinyint_col: TINYINT) + (1:
SMALLINT))}}
* Analyze to {{((tinyint_col: TINYINT) + (1: SMALLINT)): INT)}}
If we repeated the process again, we'd get: {{((tinyint_col: TINYINT) + (1:
INT)): BIGINT)}}
There is something basic wrong about type propagation: earlier attempts to
normalize types become inputs for later attempts to normalize types, leading to
escalating type widening.
At the same time, other parts of the query have taken copies (clones) of the
expressions. Over time, those copies get out of sync with the widened versions,
leading to type errors.
> 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]
