вт, 26 июн. 2018 г. в 15:42, Alexander Korotkov <a.korot...@postgrespro.ru>:
> On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada <sawada.m...@gmail.com> > wrote: > > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov > > <a.korot...@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?
