Re: Reducing the overhead of NUMERIC data

"Jim C. Nasby" <jnasby(at)pervasive(dot)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 instance
sign 1 bit
weight 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