On Fri, Apr 16, 2010 at 2:14 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
