Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
От | Alexander Korotkov |
---|---|
Тема | Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
Дата | |
Msg-id | CAPpHfdvewmr4PcpRjrkstoNn1n2_6dL-iHRB21CCfZ0efZdBTg@mail.gmail.com обсуждение исходный текст |
Ответ на | pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor (Alexander Korotkov <akorotkov@postgresql.org>) |
Ответы |
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
Список | pgsql-committers |
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) ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-committers по дате отправления: