Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting should be documented

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, basil(dot)bourque(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting should be documented
Date: 2019-07-27 21:41:30
Message-ID: 20190727214130.bjgyv2holjng3oeb@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-docs

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(at)momjian(dot)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 Content-Type Size
default.diff text/x-diff 10.0 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2019-07-28 00:47:44 Re: BUG #15916: Confusing upgrade message
Previous Message Tom Lane 2019-07-27 16:53:21 Re: Multiple inheritance and ALTER TABLE issue

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2019-07-30 00:42:00 Re: pg_upgrade "configdir" vs "datadir"
Previous Message Alvaro Herrera 2019-07-26 22:02:42 Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting should be documented