Re: Per-table log_autovacuum_min_duration is actually documented

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per-table log_autovacuum_min_duration is actually documented
Date: 2015-11-12 05:54:39
Message-ID: CAB7nPqSAqQCH8C0+-5hR-37P3hktW-wYXE_EmCY4+xQk=7Kb4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 12, 2015 at 9:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-11-12 06:03:17 Re: BUG #13741: vacuumdb does not accept valid password
Previous Message Etsuro Fujita 2015-11-12 05:54:10 Re: Foreign join pushdown vs EvalPlanQual