Thread: vacuum_cost_limit doc description patch

vacuum_cost_limit doc description patch

From
Martín Marqués
Date:
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

Attachment

Re: vacuum_cost_limit doc description patch

From
David Rowley
Date:
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


Re: vacuum_cost_limit doc description patch

From
Martín Marqués
Date:
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

Attachment

Re: vacuum_cost_limit doc description patch

From
Bruce Momjian
Date:
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.