Re: Per-table log_autovacuum_min_duration is actually documented

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Per-table log_autovacuum_min_duration is actually documented
Дата
Msg-id CAB7nPqSAqQCH8C0+-5hR-37P3hktW-wYXE_EmCY4+xQk=7Kb4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Per-table log_autovacuum_min_duration is actually documented  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [DESIGN] ParallelAppend
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual