"Carlo Stonebanks" <stonec.regis...@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
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
