"Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)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
The probably won't need to do that with proper configuration and
>>> 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.
In response to
pgsql-performance by date
|Next:||From: Greg Smith||Date: 2010-01-20 21:18:48|
|Subject: Re: ext4 finally doing the right thing|
|Previous:||From: Greg Smith||Date: 2010-01-20 20:34:21|
|Subject: Re: a heavy duty operation on an "unused" table kills my