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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits
Дата
Msg-id 1213.1133807480@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] snprintf() argument reordering not working
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCHES] snprintf() argument reordering not working