El 11/04/18 a las 02:04, David Rowley escribió: > On 11 April 2018 at 09:13, Martín Marqués <martin.marq...@gmail.com> wrote: >> This is a patch to add some further description, plus the upper and >> lower limits it has. > > Hi, > > + for vacuum_cost_delay. The parameter can take a value > between 1 and 10000. > > vacuum_cost_delay should be in <varname> tags. > > +1 to mentioning that we sleep for vacuum_cost_delay, but I just don't > see many other GUCs with mention of their supported range.
Thanks David for having a look. New version attached with the missing <varname> tags. > effective_io_concurrency mentions the range it supports, but this > happens to depend on USE_POSIX_FADVISE, which if undefined the maximum > setting is 0, which means the docs are wrong in some cases on that. > > vacuum_cost_limit seems fairly fixed at 0-10000 with no compile-time > conditions, so perhaps it's okay, providing we remember and update the > docs if that ever changes. I'm also adding a second patch over the config.sgml doc to fix what I believe is a misguidance in the minimum resolution time modern systems have. The patch just changes *many* for *some* systems which have a minimum resolution time of 10 milliseconds. -- Martín Marqués http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
>From a0563066bb3a0b8e662eb9e28fd5439c4f3dd5df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?= <martin.marq...@2ndquadrant.com> Date: Fri, 13 Apr 2018 09:39:11 -0300 Subject: [PATCH 1/2] Describe better vacuum_cost_limit, mentioning the lower and upper values it can take and the fact that once that value is reached the backend executing vacuum will sleep for vacuum_cost_delay milliseconds. --- doc/src/sgml/config.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5d5f2d23c4..38e4766522 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1860,8 +1860,9 @@ include_dir 'conf.d' </term> <listitem> <para> - The accumulated cost that will cause the vacuuming process to sleep. - The default value is 200. + This is the accumulated cost that will cause the vacuuming process to sleep + for <varname>vacuum_cost_delay</varname>. The parameter can take a value + between 1 and 10000. The default is 200. </para> </listitem> </varlistentry> -- 2.13.6
>From 1b41ff8743b166103fa9d5d303f3e1ffacf36dbf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?= <martin.marq...@2ndquadrant.com> Date: Fri, 13 Apr 2018 09:44:43 -0300 Subject: [PATCH 2/2] In the past there were many systems which which had an effective resolution time of 10 milliseconds. That's not entirely true any more, yet there are still *some* systems that still have that minimum resolution for time. Suggest changing *many* for *some* to comply with modern times. --- doc/src/sgml/config.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 38e4766522..55f64299ad 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1788,7 +1788,7 @@ include_dir 'conf.d' when the cost limit has been exceeded. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. - Note that on many systems, the effective resolution + Note that on some systems, the effective resolution of sleep delays is 10 milliseconds; setting <varname>vacuum_cost_delay</varname> to a value that is not a multiple of 10 might have the same results as setting it @@ -1941,7 +1941,7 @@ include_dir 'conf.d' milliseconds, and repeats. When there are no dirty buffers in the buffer pool, though, it goes into a longer sleep regardless of <varname>bgwriter_delay</varname>. The default value is 200 - milliseconds (<literal>200ms</literal>). Note that on many systems, the + milliseconds (<literal>200ms</literal>). Note that on some systems, the effective resolution of sleep delays is 10 milliseconds; setting <varname>bgwriter_delay</varname> to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple -- 2.13.6