Skip site navigation (1) Skip section navigation (2)

Re: max_fsm_pages question

From: Michael Monnerie <michael(dot)monnerie(at)is(dot)it-management(dot)at>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: max_fsm_pages question
Date: 2010-01-25 14:40:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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?:

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
Tel: 0660 / 415 65 31

// Wir haben zwei Häuser zu verkaufen:

In response to


pgsql-admin by date

Next:From: Kevin GrittnerDate: 2010-01-25 15:03:46
Subject: Re: max_fsm_pages question
Previous:From: Kevin GrittnerDate: 2010-01-25 13:24:54
Subject: Re: max_fsm_pages question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group