Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits
Date
Msg-id 1213.1133807480@sss.pgh.pa.us
Whole thread Raw
In response to Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits  (Gregory Maxwell <gmaxwell@gmail.com>)
Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The limit seems to be around 150k digits:

It's exactly 10^(128K), as I've mentioned more than once.

> So, with the patch, the storage length is going from 1000 digits to 508,
> but the computational length is reduced from around 150k digits to 508. 
> Now, because no one has complained about the 1000-digit limit, it is
> unlikely that anyone is doing calculations over 1000 or the would have
> had problems with storing the value,

Only if they declared their columns as numeric(N) and not just plain
unconstrained numeric.  Not to mention the possibility that they're
doing the same thing you just did, ie computing values and returning
them to the client without ever storing them in a table.  So I don't
think the above reasoning is defensible.

> Not only does 4000! not work, but 400! doesn't even work.  I just lost
> demo "wow" factor points!

It looks like the limit would be about factorial(256).

The question remains, though, is this computational range good for
anything except demos?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] snprintf() argument reordering not working
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] snprintf() argument reordering not working