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-headerformat1 bit: actual number sign (POS or NEG, disallow NaN)6 bits: weight, room for -32 .. 317 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.
regards, tom lane