Re: Let's drop two obsolete features which are bear-traps for novices - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: Let's drop two obsolete features which are bear-traps for novices
Date
Msg-id A737B7A37273E048B164557ADEF4A58B17D8BC03@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Re: Let's drop two obsolete features which are bear-traps for novices  (David Fetter <david@fetter.org>)
Responses Re: Let's drop two obsolete features which are bear-traps for novices  (David Fetter <david@fetter.org>)
List pgsql-hackers
David Fetter wrote:
> On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
>> Just out of curiosity, why is Oracle's NUMBER (I assume you are
>> talking about this) so fast?
> 
> I suspect that what happens is that NUMBER is stored as a native type
> (int2, int4, int8, int16) that depends on its size and then cast to
> the next upward thing as needed, taking any performance hits at that
> point.  The documentation hints (38 decimal places) at a 128-bit
> internal representation as the maximum.  I don't know what happens
> when you get past what 128 bits can represent.

No, Oracle stores NUMBERs as variable length field (up to 22 bytes),
where the first byte encodes the sign and the comma position and the
remaining bytes encode the digits, each byte representing two digits
in base-100 notation (see Oracle Metalink note 1007641.6).

So it's not so different from PostgreSQL.
No idea why their arithmetic should be faster.

Yours,
Laurenz Albe

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: tracking commit timestamps
Next
From: Simon Riggs
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument