[
https://issues.apache.org/jira/browse/HIVE-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626636#comment-13626636
]
Carter Shanklin commented on HIVE-4271:
---------------------------------------
Gunther, one thing to consider is Teradata interoperability and they support up
to 38 rather than 36. They claim to do this with 16 bytes. See
http://developer.teradata.com/tools/articles/how-many-digits-in-a-decimal
I believe SQL Server is also 38 but I'm not sure. If we can get 38 that would
be ideal from a compatibility point of view. If there is a big performance hit
due to encoding or whatever other reason that's a good reason to go with 36
rather than 38 since there's probably not too many apps using 37 or 38. There
are bound to be some out there somewhere though.
Last thought, starting with 18 is fine since it futureproofed from a DDL point
of view but there is good upside to being able to make stronger compatibility
statements.
> 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
