vacuum_cost_limit doc description patch
Hi,
Today looking for information on hard limits for
autovacuum_vacuum_cost_limit I found myself with a very short
description in the docs.
This is a patch to add some further description, plus the upper and
lower limits it has.
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
Attachments:
0001-Describe-better-vacuum_cost_limit-mentioning-the-low.patchtext/x-patch; charset=US-ASCII; name=0001-Describe-better-vacuum_cost_limit-mentioning-the-low.patchDownload
From 3a1aa5de682ee6f6cbd1086845ce845409156186 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=
<martin.marques@2ndquadrant.com>
Date: Tue, 10 Apr 2018 18:03:52 -0300
Subject: [PATCH] Describe better vacuum_cost_limit, mentioning the lower and
upper values it can take.
---
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..fe7a6d91df 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 vacuum_cost_delay. The parameter can take a value between 1 and 10000.
+ The default is 200.
</para>
</listitem>
</varlistentry>
--
2.13.6
On 11 April 2018 at 09:13, Martín Marqués <martin.marques@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.
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.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
El 11/04/18 a las 02:04, David Rowley escribió:
On 11 April 2018 at 09:13, Martín Marqués <martin.marques@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
Attachments:
0001-Describe-better-vacuum_cost_limit-mentioning-the-low.patchtext/x-patch; name=0001-Describe-better-vacuum_cost_limit-mentioning-the-low.patchDownload
From a0563066bb3a0b8e662eb9e28fd5439c4f3dd5df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=
<martin.marques@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
0002-In-the-past-there-were-many-systems-which-which-had-.patchtext/x-patch; name=0002-In-the-past-there-were-many-systems-which-which-had-.patchDownload
From 1b41ff8743b166103fa9d5d303f3e1ffacf36dbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=
<martin.marques@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
On Fri, Apr 13, 2018 at 09:56:18AM -0300, Martín Marqués wrote:
El 11/04/18 a las 02:04, David Rowley escribió:
On 11 April 2018 at 09:13, Martín Marqués <martin.marques@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.
Patch applied to master, though I removed the valid range part of the
patch. I also liked the many-to-some change since it is more accurate.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.