From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: reclaiming diskspace bloat w/near-zero downtime |
Date: | 2004-12-03 16:05:02 |
Message-ID: | 200412030905.02899.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2004-12-03 16:07:28 | Re: general questions on Postgresql and deployment on |
Previous Message | Joshua D. Drake | 2004-12-03 15:59:14 | Re: table inheritance and DB design |