On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov > <a.korotkov@postgrespro.ru> wrote: > > So, I propose to just > > increase maximum value for both GUC and reloption. See the attached > > patch. It also changes calculations _bt_vacuum_needs_cleanup() for > > better handling of large values (just some kind of overflow paranoia). > > The patch looks good to me.
Pushed, thanks!
Thank you for the enhancement. Now Index Only Scans over Append-Only tables in Postgres can be implemented, even if it requires manual kicking of VACUUM over large table, and that's a great enhancement for moving object databases. :)
My eye catches another thing, the error message in tests is:
DETAIL: Valid values are between "0.000000" and "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000".
a) do we really need to print digits of dblmax? "Valid values are double precision, non-negative"?
b) double precision binary-to-decimal noise starts at 16th digit. Why does it stop at the point, and we have precise ".000000"? Does it bite the conversion somewhere else too?