Re: [HACKERS] Reducing the overhead of NUMERIC data

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2005-11-01 at 17:55 -0500, Tom Lane wrote:
>> 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)

> I've coded a short patch to do this, which is the result of two
> alternate patches and some thinking, but maybe not enough yet.

What your patch does is

sign 2 bits
weight 8 bits (-128..127)
dscale 6 bits (0..63)

which is simply pretty lame: weight effectively has a factor of 8 more
dynamic range than dscale in this representation. What's the point of
being able to represent 1 * 10000 ^ -128 (ie, 10^-512) if the dscale
only lets you show 63 fractional digits? You've got to allocate the
bits in a saner fashion. Yes, that takes a little more work.

Also, since the internal (unpacked) calculation representation has a
much wider dynamic range than this, it'd probably be appropriate to add
some range checks to the code that forms a packed value from unpacked.

regards, tom lane