| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Rick <richard(dot)branton(at)ca(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: autovacuum strategy / parameters |
| Date: | 2010-05-01 03:08:20 |
| Message-ID: | 20100501030820.GI3151@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Josh Berkus escribió:
> #autovacuum_vacuum_scale_factor = 0.2
>
> This is set because in my experience, 20% bloat is about the level at
> which bloat starts affecting performance; thus, we want to vacuum at
> that level but not sooner. This does mean that very large tables which
> never have more than 10% updates/deletes don't get vacuumed at all until
> freeze_age; this is a *good thing*. VACUUM on large tables is expensive;
> you don't *want* to vacuum a billion-row table which has only 100,000
> updates.
Hmm, now that we have partial vacuum, perhaps we should revisit this.
> It would be worth doing a DBT2/DBT5 test run with different autovac
> settings post-8.4 so see if we should specifically change the vacuum
> threshold.
Right.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cédric Villemain | 2010-05-01 10:52:35 | Re: Optimization idea |
| Previous Message | Josh Berkus | 2010-04-30 22:50:54 | Re: autovacuum strategy / parameters |