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