Re: Fwd: Indexes and Tables: Growth and Treatment - Mailing list pgsql-general

From Matthew T. O'Connor
Subject Re: Fwd: Indexes and Tables: Growth and Treatment
Date
Msg-id 1090194386.4966.5.camel@zedora2
Whole thread Raw
In response to Fwd: Indexes and Tables: Growth and Treatment  (Thomas F.O'Connell <tfo@sitening.com>)
Responses Re: Indexes and Tables: Growth and Treatment  (Thomas F.O'Connell <tfo@sitening.com>)
List 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 by date:

Previous
From: Ian Barwick
Date:
Subject: Re: nmap not showing postgres
Next
From: Tom Lane
Date:
Subject: Re: Horology & stats tests fail in 7.4.3/RH 9