Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented
От | Bruce Momjian |
---|---|
Тема | Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented |
Дата | |
Msg-id | 20190727214130.bjgyv2holjng3oeb@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented
|
Список | 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 +
Вложения
В списке pgsql-bugs по дате отправления: