[
https://issues.apache.org/jira/browse/HIVE-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627100#comment-13627100
]
Gunther Hagleitner commented on HIVE-4271:
------------------------------------------
Thanks Carter and Eric for the feedback. I've opened HIVE-4320 in response to
your comments. I'd like to think through how we're going to do math on these
numbers, but you make a great point.
I'd still like to move forward with this jira and do the rest in HIVE-4320.
> 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
