[ 
https://issues.apache.org/jira/browse/HIVE-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624237#comment-13624237
 ] 

Gunther Hagleitner commented on HIVE-4271:
------------------------------------------

[~ehans]: Thanks for the feedback. I like your idea of the single LONG default, 
however I'm not sure we'll be able to easily do that. Right now there are no 
defaults. Just one "decimal" type with a max precision (of 36) - reducing that 
to 18 would be a really small range. The plan is to eventually extend to 
decimal(p)/decimal(p,s), but at that point I'm thinking the default "decimal" 
type will still have to be the max precision (e.g.: that'll be the fallback for 
decimal operations where we don't know the exact precision returned). We'll 
see, hopefully we can at least coach folks to use as little as they need for 
improved performance.
                
> Limit precision of decimal type
> -------------------------------
>
>                 Key: HIVE-4271
>                 URL: https://issues.apache.org/jira/browse/HIVE-4271
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Gunther Hagleitner
>            Assignee: Gunther Hagleitner
>         Attachments: HIVE-4271.1.patch, HIVE-4271.2.patch, HIVE-4271.3.patch, 
> HIVE-4271.4.patch, HIVE-4271.5.patch
>
>
> The current decimal implementation does not limit the precision of the 
> numbers. This has a number of drawbacks. A maximum precision would allow us 
> to:
> - Have SerDes/filformats store decimals more efficiently
> - Speed up processing by implementing operations w/o generating java 
> BigDecimals
> - Simplify extending the datatype to allow for decimal(p) and decimal(p,s)
> - Write a more efficient BinarySortable SerDe for sorting/grouping/joining
> Exact numeric datatype are typically used to represent money, so if the limit 
> is high enough it doesn't really become an issue.
> A typical representation would pack 9 decimal digits in 4 bytes. So, with 2 
> longs we can represent 36 digits - which is what I propose as the limit.
> Final thought: It's easier to restrict this now and have the option to do the 
> things above than to try to do so once people start using the datatype.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to