[jira] [Created] (IMPALA-7855) Excessive type widening leads to unnecessary casts

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

Paul Rogers created IMPALA-7855:
-----------------------------------

             Summary: 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


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)