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

Reply via email to