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

From Michael Paquier
Subject Re: Per-table log_autovacuum_min_duration is actually documented
Date
Msg-id CAB7nPqSAqQCH8C0+-5hR-37P3hktW-wYXE_EmCY4+xQk=7Kb4w@mail.gmail.com
Whole thread Raw
In response to Re: Per-table log_autovacuum_min_duration is actually documented  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 12, 2015 at 9:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>> I think you're remembering this:
>>> http://www.postgresql.org/message-id/20150402205713.GB22175@eldon.alvh.no-ip.org
>
>> Right. Thanks. Do you think we'd still want a patch to improve that?
>
> Give it a try if you like, and see whether it seems to improve matters.
> I did not try moving material around like that in the patch I committed
> earlier today.

Hm. I am not sure we are quite at the point of hacking something. The
pinpoint regarding such a change would be where to gather a
description of all those storage parameters, which are already divided
by type: per-table and per-index. A new section called "Storage
Parameters" in the chapter "Server Configuration", just after "Query
Planning" for example would make sense. Then we could have a section
for indexes parameters, one for tables, and one for parameters shared
between both, like fillfactor. Then we would need to add to link to
this new section in the pages of CREATE/ALTER TABLE/INDEX.

Does that make sense? The fact that we have per-index and per-table
parameters is perhaps an argument sufficient to keep things the way
they are now, though we had better add an indexterm for example for
fillfactor.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [DESIGN] ParallelAppend
Next
From: Etsuro Fujita
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual