From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits |
Date: | 2005-12-02 20:37:56 |
Message-ID: | 6797.1133555876@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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.
Bruce is entirely incorrect on the last two points (although he may have
found a bug in his copy of psql, see thread in -patches if you care).
The actual effective limit on NUMERIC is presently 10^128K, which is
probably enough to count the femtoseconds remaining until the heat death
of the universe, and then multiply that by the number of elementary
particles therein ;-). And it is checked --- compare what you get from
select pow(10::numeric, 131071);
select pow(10::numeric, 131072);
Restricting NUMERIC to 10^508 would therefore be a significant reduction
in dynamic range. Whether anyone seriously cares is another question
--- if you do want unlimited-precision arithmetic, you should probably
be doing it in some other software anyway. (The NUMERIC routines get
painfully slow with tens of thousands of digits :-(.)
The current 1000-digit limit on declared NUMERIC columns is basically an
artificial limit, with pretty much the same reasoning as the artificial
limit on declared VARCHAR length: if you think you need more than 1000
digits then you probably ought not be declaring a specific upper limit
at all.
BTW, the limit is on dynamic range, not number of digits: the first
significant digit has to be within 128K places of the decimal point
(or, if this patch is applied, within 508 places of the decimal point),
but you can have as many digits as you like after that one. It would be
reasonable to describe the patched system as allowing 500 places before
and 500 places after the decimal point, or 1000 digits overall.
So the question is, is anyone doing anything with Postgres that would be
affected by a 500-place limit, or even come close to being affected?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-02 20:40:30 | Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits |
Previous Message | Will Glynn | 2005-12-02 20:29:32 | Re: memory leak under heavy load? |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-12-02 20:44:11 | Re: Numeric 508 datatype |
Previous Message | Joshua D. Drake | 2005-12-02 20:27:41 | Re: [HACKERS] Should libedit be preferred to libreadline? |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-12-02 20:44:11 | Re: Numeric 508 datatype |
Previous Message | Joshua D. Drake | 2005-12-02 20:27:41 | Re: [HACKERS] Should libedit be preferred to libreadline? |