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 по дате отправления: