Re: Reducing the overhead of NUMERIC data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 29084.1130885738@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Reducing the overhead of NUMERIC data  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> FWIW, most databases I've used limit NUMERIC to 38 digits, presumably to
> fit length info into 1 or 2 bytes. So there's something to be said for a
> small numeric type that has less overhead and a large numeric (what we
> have today).

I don't think it'd be worth having 2 types.  Remember that the weight is
measured in base-10k digits.  Suppose for instancesign        1 bitweight        7 bits (-64 .. +63)dscale        8
bits(0..255)
 
This gives us a dynamic range of 1e-256 to 1e255 as well as the ability
to represent up to 255 displayable fraction digits.  Does anyone know
any real database applications where that's not enough?

(I'm neglecting NaN here in supposing we need only 1 bit for sign,
but we could have a special encoding for NaN.  Perhaps disallow the
weight = -64 case and use that to signal NaN.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Reducing the overhead of NUMERIC data
Next
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data