On Mon, 2007-06-18 at 11:32 -0400, Tom Lane wrote: > Andreas Pflug <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
