You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Zoltán Borók-Nagy (JIRA)" <ji...@apache.org> on 2018/08/17 15:59:00 UTC

[jira] [Assigned] (IMPALA-7412) width_bucket() function overflows too easily

     [ https://issues.apache.org/jira/browse/IMPALA-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Zoltán Borók-Nagy reassigned IMPALA-7412:
-----------------------------------------

    Assignee: Zoltán Borók-Nagy

> width_bucket() function overflows too easily
> --------------------------------------------
>
>                 Key: IMPALA-7412
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7412
>             Project: IMPALA
>          Issue Type: Bug
>            Reporter: Zoltán Borók-Nagy
>            Assignee: Zoltán Borók-Nagy
>            Priority: Major
>
> I looked at the failing query:
> {noformat}
> select width_bucket(cast(-0.51111065802795359821573 as decimal(28,28)), cast(-7.247919472444366553466758690723 as decimal(31,30)), cast(2.6 as decimal(22,17)), 189748626);{noformat}
> and the problem is that in WidthBucketImpl() we want to cast num_buckets to a decimal with ARG_TYPE_PRECISION and ARG_TYPE_SCALE.
> ARG_TYPE_PRECISION and ARG_TYPE_SCALE are determined by the Frontend in
> {noformat}
> FunctionCallExpr.analyzeImpl()->castForFunctionCall()->getResolvedWildCardType(){noformat}
> getResolvedWildCardType() only looks at the arguments that correspond to wildcard decimal parameters:
> {noformat}
> if (!fnArgs[ix].isWildcardDecimal()) continue;{noformat}
> Therefore it doesn't take the INT argument (num_buckets) into account and determines a decimal with precision 35 and scale 30.
> We could modify getResolvedWildCardType() to consider other arguments as well. This query would fail again because INT needs 10 digits precision with 0 digits scale => the determined decimal would need precision 40 instead of 35. It is an error because Impala decimals can only have precision 38 at most.
> A better approach for this case would be to figure out the exact number of the digits from the literal expression 189748626 => 9. However, that would also fail because it would need precision 39.
> If we want to cast num_buckets to a decimal type we cannot make this query successful without information loss.
>  
> The other approach is to modify WidthBucketImpl() to interpret its parameters as integers, because all of them have the same byte size, precision, and scale.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org