From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris <lists(at)deksai(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: stats collector suddenly causing lots of IO |
Date: | 2010-04-16 18:14:53 |
Message-ID: | 4BC8A91D.9030709@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
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.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Kupershmidt | 2010-04-16 18:35:56 | Re: stats collector suddenly causing lots of IO |
Previous Message | Josh Kupershmidt | 2010-04-16 17:43:17 | Re: stats collector suddenly causing lots of IO |