Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented
Date
Msg-id 20190727214130.bjgyv2holjng3oeb@momjian.us
Whole thread Raw
In response to Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented
List pgsql-bugs
On Fri, Jul 26, 2019 at 06:02:42PM -0400, Alvaro Herrera wrote:
> Now you could complain that this is inconsistent with other
> descriptions; for example, log_autovacuum_min_duration talks about
> milliseconds, which sounds a bit archaic to me:
> 
>    Causes each action executed by autovacuum to be logged if it ran for
>    at least the specified number of milliseconds. Setting this to zero
>    logs all autovacuum actions. -1 (the default) disables logging
>    autovacuum actions. For example, if you set this to 250ms then all
>    automatic vacuums and analyzes that run 250ms or longer will be
>    logged. In addition, when this parameter is set to any value other
>    than -1, a message will be logged if an autovacuum action is skipped
>    due to a conflicting lock or a concurrently dropped relation.
>    Enabling this parameter can be helpful in tracking autovacuum
>    activity. This parameter can only be set in the postgresql.conf file
>    or on the server command line; but the setting can be overridden for
>    individual tables by changing table storage parameters.
> 
> 
> I'm not really sure what's a good way to attack this problem, but I
> doubt that focusing on just one description is a sufficient solution.

Yes, I looked at this earlier in the week and had the same conclusion. 
I went over config.sgml and saw many inconsistencies of the same type
being complained about here.

I went through the file and found a number of cases using milliseconds
and kilobytes that were unclear, and adjusted them.  I dealt only with
the cases where the base unit (seconds/bytes) was not the default unit. 
Patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Multiple inheritance and ALTER TABLE issue
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #15916: Confusing upgrade message