Re: determining max_fsm_pages - Mailing list pgsql-performance

From Tom Lane
Subject Re: determining max_fsm_pages
Date
Msg-id 15929.1099060643@sss.pgh.pa.us
Whole thread Raw
In response to determining max_fsm_pages  (Patrick Hatcher <pathat@comcast.net>)
List pgsql-performance
Patrick Hatcher <pathat@comcast.net> writes:
> My question is this:  I have about 8 databases running on this server.
> When I do a vacuum full on each of these databases, there is a INFO
> section that I assume is the total pages used for that database.  Should
> add ALL these individual pages together and pad the total and use this
> as my new max_fsm_pages?  Should I do the same thing with max_fsm_relations?

No, the numbers shown at the end of a vacuum verbose printout reflect
the current cluster-wide FSM demand.  BTW you do *not* want to use FULL
because that's not going to reflect the FSM requirements when you are
just running normal vacuums.

I would vacuum all your databases (to make sure each one's FSM contents
are pretty up-to-date) and then take the numbers shown by the last one
as your targets.

If you find yourself having to raise max_fsm_relations, it may be
necessary to repeat the vacuuming cycle before you can get a decent
total for max_fsm_pages.  IIRC, the vacuum printout does include in
"needed" a count of pages that it would have stored if it'd had room;
but this is only tracked for relations that have an FSM relation entry.

            regards, tom lane

pgsql-performance by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: determining max_fsm_pages
Next
From: Markus Bertheau
Date:
Subject: Re: can't handle large number of INSERT/UPDATEs