Return-Path: X-Original-To: apmail-hive-dev-archive@www.apache.org Delivered-To: apmail-hive-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3F2F1FD82 for ; Mon, 1 Apr 2013 08:05:18 +0000 (UTC) Received: (qmail 5099 invoked by uid 500); 1 Apr 2013 08:05:17 -0000 Delivered-To: apmail-hive-dev-archive@hive.apache.org Received: (qmail 4530 invoked by uid 500); 1 Apr 2013 08:05:16 -0000 Mailing-List: contact dev-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hive.apache.org Delivered-To: mailing list dev@hive.apache.org Received: (qmail 4489 invoked by uid 500); 1 Apr 2013 08:05:16 -0000 Delivered-To: apmail-hadoop-hive-dev@hadoop.apache.org Received: (qmail 4467 invoked by uid 99); 1 Apr 2013 08:05:16 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Apr 2013 08:05:16 +0000 Date: Mon, 1 Apr 2013 08:05:16 +0000 (UTC) From: "Gunther Hagleitner (JIRA)" To: hive-dev@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HIVE-4271) Limit precision of decimal type MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HIVE-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gunther Hagleitner updated HIVE-4271: ------------------------------------- Attachment: HIVE-4271.1.patch > 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 > > > 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