Re: Reducing NUMERIC size for 8.3

On Mon, 2007-06-18 at 12:44 -0400, Tom Lane wrote:
> 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.

> 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.

I think representing zero as compactly as possible is worth the trouble,
so that in itself is enough for me to say Yes. Rest seems good too.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com