On Tue, Jun 26, 2018 at 3:59 PM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
>
> On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov
> <akorotkov@postgresql.org> wrote:
> > vacuum_cleanup_index_scale_factor is used barely to protect against
> > stalled index statistics. And after detailed consideration it appears
> > that risk of stalled index statistics is low. And it would be nice to
> > allow advanced users setting higher values of
> > vacuum_cleanup_index_scale_factor. So, set upper limit for these
> > GUC and reloption to DBL_MAX.
>
> BTW, this line looks cumbersome.
>
> +DETAIL: Valid values are between "0.000000" and
>
"179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000".
>
> It's not something introduced by this patch, because other reloptions
> behave the same. Should we change output format for real reloption
> boundaries to '%g' (as guc.c does). It looks much better.
>
> ERROR: -1 is outside the valid range for parameter "random_page_cost"
> (0 .. 1.79769e+308)
See attached patch changing output format for reloption real
boundaries from "%f" to "%g".
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company