[ https://issues.apache.org/jira/browse/IMPALA-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Armstrong resolved IMPALA-3437. ----------------------------------- Resolution: Fixed Fix Version/s: Impala 2.11.0 Fixed when DECIMAL_V2 = true. IMPALA-3437: DECIMAL_V2: avoid implicit decimal->double conversion This changes the behaviour of applying an arithmetic operator to constant DECIMAL and non-DECIMAL arguments. In DECIMAL_V1, this caused an implicit conversion to floating point, which caused users a lot of confusion in some cases. In DECIMAL_V2 the typing rules are simplified: constant decimals are treated the same as any other decimals. Testing: Added some expression tests for different arithmetic operators and binary predicates (the two Expr subclasses that call convertNumericLiteralsFromDecimal()). Extended analyzer tests to test DECIMAL_V2 behaviour. Added many additional test for various combinations of literals and non-literals to get better coverage of existing and new behaviour. Ran core tests. Change-Id: Ie419a75784eec2294947103e6e1465dfadfc29da Reviewed-on: http://gerrit.cloudera.org:8080/7916 Reviewed-by: Tim Armstrong <tarmstr...@cloudera.com> Tested-by: Impala Public Jenkins --- > Consider changing arithmetic conversions to produce decimal in more cases > ------------------------------------------------------------------------- > > Key: IMPALA-3437 > URL: https://issues.apache.org/jira/browse/IMPALA-3437 > Project: IMPALA > Issue Type: Improvement > Components: Frontend > Affects Versions: Impala 2.5.0 > Reporter: Tim Armstrong > Assignee: Tim Armstrong > Priority: Minor > Labels: compatibility > Fix For: Impala 2.11.0 > > > The conversion rules for mixing decimals and integers are a little confusing. > {code} > select 10.0 / 3 > {code} > results in a double because it has a decimal literal and non-decimal literal > argument. > But > {code} > select 10.0 / 3.0 > {code} > results in a decimal because it has two decimal literal arguments. > Part of the justification for this is that decimal was significantly slower > than double, so we didn't want users to see sudden performance regressions. > However, we've since improved decimal performance a lot so we should consider > revisiting this behaviour. > The relevant code is Expr.convertNumericLiteralsFromDecimal() -- This message was sent by Atlassian JIRA (v6.4.14#64029)