Re: Reducing NUMERIC size for 8.3

I wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Anything shorter than the shortest possible numeric representation can
>> implicitly be interpreted as some alternate compact representation. I
>> already had a patch that stored small integers in a single
>> NumericDigit without any numeric header at all.

> That's getting well beyond the realm of reason IMHO. I doubt you can
> merge it with this proposal anyway --- how will you disambiguate from
> zero with a positive dscale ("0.00")?

Hmm, I take that back: it could be merged with this proposal pretty
easily. Again assuming that we move the POS/NEG/NAN/SHORT "sign"
flags to the first header word, we can have:

Sign=NAN: it's a NAN, regardless of anything else. We may as well
store NAN as just 2 bytes.

Sign=SHORT: it's a non-NAN with limited weight and dscale range,
as per my proposal. A zero value would still be only 2 bytes,
but anything else is longer. (This would be needed only for zero
with nonzero dscale, though.)

Sign=POS or NEG: if length == 2 bytes then interpret the remaining
14 bits as a single NBASE digit, with assumed weight and dscale 0.
This allows storing integers up to +/-9999 in 2 bytes (+ 1 byte
varlena header). If length > 2 then it is a traditional-format
numeric.

I'm not entirely convinced this is worth the extra pack/unpack
logic, since said integers would be 4 bytes (+1 byte header) in
the sign=SHORT representation, which is not that much more.
Also, this means at least three different representations of some
values, which is going to be a headache for comparison and hashing.
But the bit-space is there.

regards, tom lane