Re: max_fsm_pages question

On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Michael Monnerie wrote:
> > why did postgres suddenly decide to remove the old cruft suddenly?
>
> Have you read through this yet?:
>
> http://www.postgresql.org/docs/8.3/interactive/runtime-config-resourc
> e.html#RUNTIME-CONFIG-RESOURCE-FSM

Yes I did.

> > Autovacuum is on, the nightly backups do an extra "vacuum analyze",
> > and once a week a CLUSTER is done for the big tables.
>
> You should probably make that a "vacuum analyze verbose" to get a
> good idea of where you should set max_fsm_pages, and to look for
> where you are accumumlating free space to track.

That's why I find it strange. I always log the VACUUM VERBOSE ANALYZE
command, it is run nightly:
INFO: free space map contains 21517 pages in 107 relations
DETAIL: A total of 22912 page slots are in use (including overhead).
22912 page slots are required to track all free space.
Current limits are: 150000 page slots, 1000 relations, using 984 kB.

So, as there was that one relation that was bloatet - how could it be?
Autovaccuum, nightly vacuum analyze, weekly cluster - and still a heavy
bloated toast* something. I must do something wrong.

--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://it-management.at
Tel: 0660 / 415 65 31

// Wir haben zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://willhaben.at/iad/realestate/object?adId=15923011