Re: Fwd: Indexes and Tables: Growth and Treatment

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: Fwd: Indexes and Tables: Growth and Treatment
Дата
Msg-id 1090194386.4966.5.camel@zedora2
обсуждение исходный текст
Ответ на Fwd: Indexes and Tables: Growth and Treatment  (Thomas F.O'Connell <tfo@sitening.com>)
Ответы Re: Indexes and Tables: Growth and Treatment  (Thomas F.O'Connell <tfo@sitening.com>)
Список pgsql-general
Regular vacuum will (almost) never return your table to it's minimum
size.  I don't think it's unreasonable for a table that is 4MB after a
vacuum full, to grow to 11MB, especially if it's a very active table.

The important question is does it keep growing?  Or does it reach a
steady state size?  There is no point in reclaiming space via VACUUM
FULL when that space will need to be reallocated shortly.

So does the table growth eventually plateau?  Or do they grow
indefinitely?  If they are growing without bound, then you might try
some more aggressive thresholds for pg_autovacuum, or perhaps more FSM
space.

Matthew


On Sun, 2004-07-18 at 12:13, Thomas F.O'Connell wrote:
> Matthew,
>
> Here's some more feedback on our use of pg_autovaccum. It's clear
> thatit's working and that it's helping, but even after increasing
> ourmax_fsm_pages substantially (to in excess of what vacuum
> verbosesuggests is needed), we're still seeing pretty a rapid increase
> indisk usage.
>
> It used to be that nightly reindexing helped substantially, but am
> Iwrong in thinking that the frequency of dynamic analysis is
> helpingkeep index size down?
>
> Anyway, the bottom line is that it still seems like a vacuum full on
> aperiodic basis is necessary to keep growth rates in check. We
> trackboth table and index size, and our max table grows pretty
> rapidly(over the course of a few days) from about 4 MB to about 11 MB
> withpg_autovacuum running. After a vacuum full, it returns to about 4
> MB.
>
> Are there any other postgresql.conf parameters that I should belooking
> at as far as allowing pg_autovacuum to work more effective interms of
> disk reclamation? Is it possible that my max_fsm_pages isstill too
> low?



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

Предыдущее
От: Ian Barwick
Дата:
Сообщение: Re: nmap not showing postgres
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Horology & stats tests fail in 7.4.3/RH 9