Re: Reducing NUMERIC size for 8.3

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I had a thought though: it's possible to reduce the header overhead for
> typical-size numbers without giving up the ability to store large ones.
> This is because the POS/NEG/NAN sign possibilities leave one unused bit
> pattern. Hence:

I had a whack and doing something similar to this a while back -- though I was
more concerned with optimizing very small numeric variables, especially small
integers and typical currency-sized quantities.

The bottleneck I ran into was desupporting the macros which access the sign,
display scale, etc. Those are currently in numeric.h making them--in theory--
publicly available outside the internal functions. Afaik nothing actively uses
them outside of numeric.c though.

If we're happy desupporting those macros and not replacing them with anything
comparable then there are additional bits of state hidden in the varlena size.
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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com