Re: Autovacuum in the backend

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Autovacuum in the backend
Дата
Msg-id 200506151001.31369.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: Autovacuum in the backend  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Ответы Re: Autovacuum in the backend  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
Qingqing,

> add a parameter to let user pass in the configuration parameters:
> * autovacuum_command = "-s 100 -S 1 ..."

um, can we have these as separate GUCs and not lumped together as a string?  
i.e.:
autovacuum_frequency = 60  #seconds, 0 = disable
autovacuum_vacuum_threshold = 200
autovacuum_vacuum_multiple = 0.5
autovacuum_analyze_threshold = 100
autovacuum_analyze_multiple = 0.4

AV should be disabled by default.  It should also automatically use the global 
vacuum_delay settings.

> But it would be very nice to have something _similar_ to FSM, say DSM
> (dead space map), which is filled in when a tuple is marked as "dead for
> all running backends", which could be used to implement a vacuum which
> vacuums only those pages, which do actually contain removable tuples.

Speaking of FSM improvements, it would be **really** useful to have a pg_stats 
view that let you know how full the FSM was, overall.  something like:
pg_stats_fsm_usage
fsm_relations    fsm_relations_used    fsm_pages        fsm_pages_used
1000            312                200000        11579

This would allow for other schemes of vacuum automation.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: LGPL
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: max_fsm_pages >800k ... ?