Re: reclaiming diskspace bloat w/near-zero downtime

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

In response to

Browse pgsql-general by date

  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