"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq