Re: Per-table log_autovacuum_min_duration is actually documented - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Per-table log_autovacuum_min_duration is actually documented
Date
Msg-id 19201.1447274357@sss.pgh.pa.us
Whole thread Raw
In response to Re: Per-table log_autovacuum_min_duration is actually documented  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Per-table log_autovacuum_min_duration is actually documented  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Should it read "Overrides log_autovacuum_min_duration for autovacuum
>> operations on this specific table or toast table"?

> The same applied for all the other autovacuum and autoanalyze
> parameters. Do you think that we should add in the top paragraph of
> section "Storage Parameters" a mention of the type "If this parameter
> has a server-wide equivalent parameter, the per-table value overrides
> its server-wide equivalent if defined" or similar.

There's a whole lot of inconsistency in this area, apparently.  Some of
the entries in runtime-config-autovacuum are marked as being overridable
by storage parameters, some aren't (in particular this one is not, which
may be the origin of Bruce's complaint).  Some of the entries in
SQL-CREATETABLE-storage-parameters use the "custom" phraseology, some
don't but instead duplicate (or more often, rephrase poorly) the
documentation of the underlying GUC.  I think duplication is a bad
strategy here.  But I still don't care for "custom", perhaps because it's
been stretched to the point of being nearly meaningless elsewhere in the
system.  "Per-table" is used in other sentences in this same area, and
that seems like a better description.

I'll try to make this better.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
Next
From: Tom Lane
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)