Обсуждение: 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
Вложения
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
Вложения
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.