hive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: DECIMAL precision is too small
Date Sun, 29 Jun 2014 14:03:54 GMT
Sure. I was just brining that up in the case anyone attempts this approach
without understanding that bit of info.


On Sun, Jun 29, 2014 at 10:01 AM, Brian Jeltema <
brian.jeltema@digitalenvoy.net> wrote:

> Right, but in my case the numbers are never negative.
>
> On Jun 29, 2014, at 9:52 AM, Edward Capriolo <edlinuxguru@gmail.com>
> wrote:
>
> That does not work if your sorting negative numbers btw. As you would have
> to - pad and reverse negative numbers.
>
>
> On Sun, Jun 29, 2014 at 6:35 AM, Brian Jeltema <
> brian.jeltema@digitalenvoy.net> wrote:
>
>> Probably not generally interesting. I needed the numeric value for an
>> ‘order by’ clause, so I store the
>> value as a string and do "order  by lpad(value, 40, ‘0’)”
>>
>> Brian
>>
>> On Jun 28, 2014, at 2:51 PM, Lefty Leverenz <leftyleverenz@gmail.com>
>> wrote:
>>
>> What was your work-around?  (If it's generally applicable, we could
>> include it in the documentation.)
>>
>> -- Lefty
>>
>>
>> On Sat, Jun 28, 2014 at 10:08 AM, Brian Jeltema <
>> brian.jeltema@digitalenvoy.net> wrote:
>>
>>> Hive doesn’t support a BigDecimal data type, as far as I know. It
>>> supports a Decimal type that
>>> is based on BigDecimal, but the precision is limited to 38 digits.
>>>
>>> However, I found a way to work around the limitation, so it’s no longer
>>> an issue for me.
>>>
>>> Brian
>>>
>>> On Jun 28, 2014, at 8:22 AM, sumit ghosh <sumitkg@yahoo.com> wrote:
>>>
>>> Did you try BigDecimal? It is the same datatype as Java BigDecimal.
>>>
>>>
>>>   On Thursday, 26 June 2014 8:34 AM, Brian Jeltema <
>>> brian.jeltema@digitalenvoy.net> wrote:
>>>
>>>
>>> Sorry, I meant 128 bit
>>>
>>> On Jun 26, 2014, at 11:31 AM, Brian Jeltema <
>>> brian.jeltema@digitalenvoy.net> wrote:
>>>
>>> > I need to represent an unsigned 64-bit value as a Hive DECIMAL. The
>>> current precision maximum is 38,
>>> > which isn’t large enough to represent the high-end of this value. Is
>>> there an alternative?
>>> >
>>> > Brian
>>> >
>>>
>>>
>>>
>>>
>>
>>
>
>

Mime
View raw message