On Mon, Sep 15, 2008 at 2:14 PM, Fernando Hevia <fhevia@ip-tel.com.ar> wrote:
>
>
>> -----Mensaje original-----
>> De: Scott Marlowe [mailto:scott.marlowe@gmail.com]
>
>> >
>> > Consider that if you are NOT going to use the decimals you should
>> > really use integer or bigint datatypes. The numeric type
>> compute much
>> > slower than integer datatypes.
>>
>> Note that if you're just converting the output the cost is
>> minimal compared to if you're doing all your math in numeric.
>> It's when you force math to happen that numeric is slower,
>> but numeric's gotten a lot of tuning in the last few years
>> and it's withing a few percentage
>> of integer for most measurements. Definitely not twice as slow or
>> anything like they once were.
>>
>
> Well, in that case the manual should be revised.
>
> 8.1.2. Arbitrary Precision Numbers
>
> The type numeric can store numbers with up to 1000 digits of precision and
> perform calculations exactly. It is especially recommended for storing
> monetary amounts and other quantities where exactness is required. However,
> arithmetic on numeric values is __very slow__ compared to the integer types,
> or to the floating-point types described in the next section.
>
> Ref: http://www.postgresql.org/docs/current/static/datatype-numeric.html
>
> The explicit "very slow" assertion scared me quite enough so to avoid
> numeric types where possible.
yeah, I agree. In the days of 7.2 it was horrifically slow (like 10
to 20 times slower most the time) to do numeric math on similar sized
numbers as int math.
Note that if you are working with numbers of 500 digits it's gonna be
a lot slower than numbers with 10 digits, but if the numbers are
similar in size, numeric has had a lot of optimization that makes it
quite usable now. which is handy when porting from oracle, where
everything is a sort-of numeric.
