Re: Calculation for Max_FSM_pages : Any rules of thumb?

Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com> wrote:
>
> I just ran a vacuum verbose on the entire DB and this came out.
>
> number of page slots needed (274144) exceeds max_fsm_pages (153600)
>
> Hence, I've changed the max to 400,000 (pulled it straight out of the
> air). How does one calculate what's the number needed anyway?

It's not simple. Every update or delete creates a "dead tuple" that
needs to be tracked by an fsm entry. So it depends on how frequently
your database is changing in between vacuum runs.

In my experience, the best bet is to do vacuum verbose on a regular
basis and get a feel for what you need. Every database load is
different.

> Another question is, based on what I've read in the archives (in my
> laptop.. No-Inet conn @ work) Since I've overran my max_FSM, I'm
> basically screwed and will have to do a vacuum verbose FULL on the
> entire DB. Crap..

You don't _need_ to. But it's generally a good idea to get table
bloat reduced.

> (I was playing with pgfouine and then I found the above piece of advice)
>
> I'm planning to run vacuum verbose full tonight/over the weekend. (is
> this sane?) Thanks for the advice..

vacuum full is sane, if that's what you mean. The only problem is that
it locks tables while working on them, so you have to take into account
what other workload might be blocked while vacuum full is working, and
how long vacuum full is liable to take.

--
Bill Moran
http://www.potentialtech.com