On Fri, Apr 16, 2010 at 2:14 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Josh Kupershmidt wrote:
>>
>> SELECT name, current_setting(name), source FROM pg_settings WHERE
>> source != 'default' AND name ILIKE '%vacuum%';
>> name | current_setting | source
>> ----------------------+-----------------+--------------------
>> vacuum_cost_delay | 200ms | configuration file
>> vacuum_cost_limit | 100 | configuration file
>> vacuum_cost_page_hit | 6 | configuration file
>>
>> Hopefully changing those three vacuum_cost_* params will speed up the
>> manual- and auto-vacuums..
>
> Those only impact manual VACUUM statements. There's a different set with
> names like autovacuum_vacuum_cost_delay that control the daemon. You can
> set those to "-1" in order to match the regular VACUUM, but that's not the
> default.
It looks like the default which I have of autovacuum_vacuum_cost_limit
= -1, which means it's inheriting the vacuum_cost_limit of 100 I had
set. I'll try bumping vacuum_cost_limit up to 1000 or so.
> You really need to sort out the max_fsm_pages setting too, because until
> that issue goes away these tables are unlikely to ever stop growing. And,
> no, you can't use CLUSTER on the system tables to clean those up.
I have max_fsm_pages = 524288 , but from the hints in the logfiles
this obviously needs to go up much higher. And it seems the only way
to compact the pg_catalog tables is VACUUM FULL + REINDEX on 8.3 -- I
had tried the CLUSTER on my 9.0 machine and wrongly assumed it would
work on 8.3, too.
Josh
