Paul Rogers created IMPALA-7966:
-----------------------------------
Summary: Analyzer does not follow Decimal V1 type propagation rules
Key: IMPALA-7966
URL: https://issues.apache.org/jira/browse/IMPALA-7966
Project: IMPALA
Issue Type: Bug
Components: Frontend
Affects Versions: Impala 3.1.0
Reporter: Paul Rogers
Assignee: Paul Rogers
Consider {{AnalyzeExprsTest.TestDecimalArithmetic()}}:
{code:java}
// Operators between decimal and numeric types should be supported. The int
// should be cast to the appropriate decimal (e.g. tinyint -> decimal(3,0)).
testDecimalExpr(decimal_10_0 + " + cast(1 as tinyint)",
ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as smallint)",
ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as int)",
ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as bigint)",
ScalarType.createDecimalType(20, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as float)",
ScalarType.createDecimalType(38, 9), ScalarType.createDecimalType(38,
8));
testDecimalExpr(decimal_10_0 + " + cast(1 as double)",
ScalarType.createDecimalType(38, 17), ScalarType.createDecimalType(38,
16));
{code}
This is rather cryptic: it means that the given expression should evaluate, in
both Decimal V1 and V2, to the given type. The last two tests have different
types for V1 and V2.
However, the above should follow the V1 rules as explained in
{{Expr.convertNumericLiteralsFromDecimal()}}:
{noformat}
* This function applies a heuristic that casts literal child exprs of this
expr from
* decimal to floating point in certain circumstances to reduce processing
cost. In
* earlier versions of Impala's decimal support, it was much slower than
floating point
* arithmetic.
{noformat}
There appears to be some bug that prevents the above from being applied. Once
the rules are applied (though a change elsewhere that somehow enabled this
path), the tests above all produce {{DOUBLE}} types. That is, the test should
be:
{code:java}
testDecimalExpr(decimal_10_0 + " + cast(1 as tinyint)",
Type.DOUBLE, ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as smallint)",
Type.DOUBLE, ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as int)",
Type.DOUBLE, ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as bigint)",
Type.DOUBLE, ScalarType.createDecimalType(11, 0));
testDecimalExpr(decimal_10_0 + " + cast(1 as float)",
Type.DOUBLE, ScalarType.createDecimalType(38, 8));
testDecimalExpr(decimal_10_0 + " + cast(1 as double)",
Type.DOUBLE, ScalarType.createDecimalType(38, 16));
{code}
The issue is marked as major because it may affect customer queries that
expected the incorrect V1 behavior.
--
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
