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

Ashutosh Chauhan commented on HIVE-4271:
----------------------------------------

Following two tests failed in CliDriver
* literal_decimal.q
    [junit] Running: diff -a 
/home/ashutosh/hive/build/ql/test/logs/clientpositive/literal_decimal.q.out 
/home/ashutosh/hive/ql/src/test/results/clientpositive/literal_decimal.q.out
    [junit] 61c61
    [junit] < -1        0       1       3.14    -3.14   99999999999999999       
99999999999999999.9999999999999 NULL    NULL
    [junit] ---
    [junit] > -1        0       1       3.14    -3.14   99999999999999999       
99999999999999999.9999999999999 1E-99   1E+99
Looks like need to update the golden file, now that we have lost ability to 
read in values like 1E-99

* serde_regex.q 
Hadoop job failed. We recently added support for decimals in regex_serde in 
HIVE-3951 , possibly related to that.

                
> 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
>
>
> 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