Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits

There is a patch under consideration for 8.2 that would reduce the
storage requirement for numeric values by two bytes, but also reduce the
range of allowed numeric values to 508 digits. The current specified
maximum NUMERIC length is 1000 (NUMERIC(1000,0)), and the maximum
computational length is 4096 digits. (Computations over 4096 digits are
silently truncated. Throwing an error instead is a TODO item I hope will
be worked on as part of this change.)

Is that an acceptable tradeoff (reduced size, reduced range) for our
users?

---------------------------------------------------------------------------

Simon Riggs wrote:
>
> Now we're into 8.2devel mode, its time to submit the previously
> discussed patch that:
>
> - reduces Numeric storage format by 2 bytes
> - limits scale to +/- 508 decimal places
>
> This is sufficient to allow Numeric to continue to be used as the
> default numeric representation for all numbers in the parser.
>
> Passes: make check on cvstip, as well as some tests not in there.
>
> Code comments explain the new format and consequences.
>
> As previously agreed, reviewing this is a 2 stage process:
> 1. review/possibly agree OK to commit
> 2. check with everybody on GENERAL that the restriction to 508 is
> acceptable
>
> Figure there's no point doing (2) until we agree the proposal/code is
> workable.
>
> As Atsushi-san point out, there is also come CPU optimization to be done
> on Numeric comparison, and also on other areas such as aggregation. I've
> not done this yet.
>
> Best Regards, Simon Riggs

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Simon Riggs wrote:
>
> Now we're into 8.2devel mode, its time to submit the previously
> discussed patch that:
>
> - reduces Numeric storage format by 2 bytes
> - limits scale to +/- 508 decimal places
>
> This is sufficient to allow Numeric to continue to be used as the
> default numeric representation for all numbers in the parser.
>
> Passes: make check on cvstip, as well as some tests not in there.
>
> Code comments explain the new format and consequences.
>
> As previously agreed, reviewing this is a 2 stage process:
> 1. review/possibly agree OK to commit
> 2. check with everybody on GENERAL that the restriction to 508 is
> acceptable
>
> Figure there's no point doing (2) until we agree the proposal/code is
> workable.
>
> As Atsushi-san point out, there is also come CPU optimization to be done
> on Numeric comparison, and also on other areas such as aggregation. I've
> not done this yet.
>
> Best Regards, Simon Riggs

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073