[
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)
