On 7/28/07, Jim C. Nasby <decibel(at)decibel(dot)org> wrote:
> What are your vacuum_cost_* settings? If you set those too aggressively
> you'll be in big trouble.
autovacuum_vacuum_cost_delay = 100
autovacuum_vacuum_cost_limit = 200
These are generally fine, autovacuum keeps up, and there is minimal impact
on the system.
vacuum_cost_delay = 100
vacuum_cost_limit = 1000
We set this cost_limit a little higher so that, in the few cases where we
have to intervene manually, vacuum runs faster.
The second pass on the vacuum means that maintenance_work_memory isn't
> large enough.
maintenance_work_mem is set to 256MB and I don't think we want to make this
any bigger by default. Like I say above, generally autovacuum runs fine.
If we do run into this situation again (lots of OOM queries and lots to
cleanup), we'll probably increase maintenance_work_mem locally and run a
vacuum in that session.
Good to know that vacuum was doing the right thing.
In response to
pgsql-performance by date
|Next:||From: Nis Jørgensen||Date: 2007-07-30 16:30:50|
|Subject: Re: Slow query with backwards index scan|
|Previous:||From: Richard Huxton||Date: 2007-07-30 14:58:31|
|Subject: Re: Questions on Tags table schema|