Re: New server to improve performance on our large and busy DB - advice?

"Carlo Stonebanks" <stonec.register@sympatico.ca> wrote:

>>  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?

If you make it too aggressive, it could impact throughput or
response time.  Odds are that the bloat from having it not
aggressive enough is currently having a worse impact.

>> 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.

The probably won't need to do that with proper configuration and
vacuum policies.

>>> 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)?

It costs six bytes of shared memory per entry.

http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSM

-Kevin