From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Alexander Korotkov <akorotkov(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
Date: | 2018-06-26 16:00:29 |
Message-ID: | 22604.1530028829@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> 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)
%g, unmodified, is a bad idea because it loses a lot of precision
in some cases (due to the assumption that nobody cares about more
than six digits). Maybe you could fix that by using %.15g or some
such, but...
I think that the original patch to use DBL_MAX was itself a bad idea
and should be rethought. It creates (what is in principle) a
platform-dependent limit, for no adequate justification. Why not
just set it to 1e9 or 1e10 or some such?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-06-26 17:11:14 | pgsql: Remove obsolete comment block in nbtsort.c. |
Previous Message | Alvaro Herrera | 2018-06-26 15:56:40 | pgsql: Enable failure to rename a partitioned index |