Re: Reducing NUMERIC size for 8.3

On Mon, 2007-06-18 at 11:32 -0400, Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> > Simon Riggs wrote:
> >> The objections to applying this patch originally were:
> >> 2. it would restrict number of digits to 508 and there are allegedly
> >> some people that want to store > 508 digits.
> >>
> > If 508 digits are not enough, are1000 digits be sufficient? Both limits
> > appear quite arbitrary to me.
>
> As per the recent discussion about factorial, the current limit of
> numeric format is 10^131071 --- there is a whole lot of daylight between
> that and 10^508.
>
> 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:
>
> 1. Switch the positions of the n_sign_dscale and n_weight fields in the
> long format, so that the sign bits are in the first word.
>
> 2. Reserve the fourth "sign" bit pattern to denote a compressed-header
> format in which there's just one uint16 header word and the
> NumericDigits start right after that. The header word could contain:
> 2 bits: "sign" distinguishing this from the two-word-header format
> 1 bit: actual number sign (POS or NEG, disallow NaN)
> 6 bits: weight, room for -32 .. 31
> 7 bits: dscale, room for 0 .. 127
>
> 3. When packing a NumericVar into a Numeric, use this short format when
> it's not a NaN and the weight and dscale are in range, else use the long
> format.
>
> Since the weight is in base-10000 digits, this bit allocation allows a
> dynamic range of about +- 10^127 which fits well with the dscale range.
> But I suspect that most of the use-cases for long numerics involve large
> integers, so it might be more useful to shave another bit or two from
> dscale and give 'em to weight.
>
> In any case, no capability is lost, unlike the original proposal; and
> this would be much less invasive than the original patch since there's
> no need to play tricks with the content of the digit array.

Sounds good. I thought there'd be a way.

Since this is your idea, would you like to do this, or should I?

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