Re: max_fsm_pages question - Mailing list pgsql-admin

From Michael Monnerie
Subject Re: max_fsm_pages question
Date
Msg-id 201001251540.19636@zmi.at
Whole thread Raw
In response to Re: max_fsm_pages question  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: max_fsm_pages question  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-admin
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

Attachment

pgsql-admin by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: max_fsm_pages question
Next
From: "Kevin Grittner"
Date:
Subject: Re: max_fsm_pages question