Re: Per-table log_autovacuum_min_duration is actually documented

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per-table log_autovacuum_min_duration is actually documented
Date: 2015-11-11 20:39:17
Message-ID: 19201.1447274357@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-11-11 20:50:45 Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
Previous Message Robert Haas 2015-11-11 20:31:10 Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)