Re: reclaiming diskspace bloat w/near-zero downtime

Поиск
Список
Период
Сортировка
От Ed L.
Тема Re: reclaiming diskspace bloat w/near-zero downtime
Дата
Msg-id 200412030905.02899.pgsql@bluepolka.net
обсуждение исходный текст
Ответ на Re: reclaiming diskspace bloat w/near-zero downtime  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On Friday December 3 2004 1:54, Martijn van Oosterhout wrote:
>
> For this, check the FSM settings. It can only keep track of a limited
> number of pages. So if your tuples are large it may not be able to
> track it all...
>
> The FSM should be set big enough to cover all the space that might be
> updated/deleted between two VACUUMs. So it might make to set the FSM to
> be quite large and vacuum (not FULL) often. These should bring the
> growth to a halt if the table really is quite empty.

Our standard approach is to set max_fsm_pages to about 2x the largest
on-disk footprint we expect from the PGDATA directory, and to set
max_fsm_relations to 4x the sum of tables + indices of all databases (to
allow for a few duplicate ad hoc databases).  This bloated cluster had
max_fsm_pages = 4M.  I assume the relevant pagesize is the default
postgresql pagesize of 8K, so 4M would handle 32GB of data?  We have
autovac running and logging its actions to file, and it has been doing what
I would have thought would be overkill vacuuming/analyzing.

Ed


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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: table inheritance and DB design
Следующее
От: Doug McNaught
Дата:
Сообщение: Re: general questions on Postgresql and deployment on