> yeah, the values are at the end. Sounds like your vacuum settings are
> too non-aggresive. Generally this is the vacuum cost delay being too
> high.
Of course, I have to ask: what's the down side?
> Yes! You can run vacuum verbose against the regular old postgres
> database (or just create one for testing with nothing in it) and
> you'll still get the fsm usage numbers from that! So, no need to run
> it against the big db. However, if regular vacuum verbose couldn't
> finish in a week, then you've likely got vacuum and autovacuum set to
> be too timid in their operation, and may be getting pretty bloated as
> we speak. Once the fsm gets too blown out of the water, it's quicker
> to dump and reload the whole DB than to try and fix it.
My client reports this is what they actualyl do on a monthly basis.
And the numbers are in:
>> NOTICE: number of page slots needed (4090224) exceeds max_fsm_pages
>> (204800)
>> HINT: Consider increasing the configuration parameter "max_fsm_pages" to
>> a value over 4090224.
Gee, only off by a factor of 20. What happens if I go for this number (once
again, what's the down side)?
Carlo