From: | Martín Marqués <martin(dot)marques(at)2ndquadrant(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum_cost_limit doc description patch |
Date: | 2018-04-13 12:56:18 |
Message-ID: | afe7730c-4ba7-3f9f-5184-1debadd18af3@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
El 11/04/18 a las 02:04, David Rowley escribió:
> On 11 April 2018 at 09:13, Martín Marqués <martin(dot)marques(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
0001-Describe-better-vacuum_cost_limit-mentioning-the-low.patch | text/x-patch | 1.1 KB |
0002-In-the-past-there-were-many-systems-which-which-had-.patch | text/x-patch | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2018-04-13 13:36:07 | Re: Covering GiST indexes |
Previous Message | Alexander Korotkov | 2018-04-13 11:10:52 | Re: Covering GiST indexes |