Re: Reducing NUMERIC size for 8.3

Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.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.
>   

I wonder if the currently waiting patch isn't Good Enough for
999.9999999999999999 % of use cases, and "all" others can use numeric
instead of numeric(1000,800) or so. Especially since there are many
patches waiting that do need further investigation and refining.

Regards,
Andreas