Skip site navigation (1) Skip section navigation (2)

Re: how to plan for vacuum?

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: how to plan for vacuum?
Date: 2007-01-25 15:54:24
Message-ID: 20070125155424.GG64372@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Please cc the list so others can reply as well...

On Thu, Jan 25, 2007 at 08:45:50AM +0100, Tomas Vondra wrote:
> > On Wed, Jan 24, 2007 at 02:37:44PM +0900, Galy Lee wrote:
> >> 1.  How do we know if autovacuum is enough for my application, or should
> >>     I setup a vacuum manually from cron for my application?
> > 
> > Generally I trust autovac unless there's some tables where it's critical
> > that they be vacuumed frequently, such as a queue table or a web session
> > table.
> 
> You can tune thresholds and scale factors for that particular table
> using pg_autovacuum. If you lower them appropriately, the vacuum will be
> fired more often for that table - but don't lower them too much, just go
> step by step until you reach values that are fine for you.

That doesn't work well if autovac gets tied up vacuuming a very large
table. Granted, when that happens there are considerations about the
long-running vacuum transaction (prior to 8.2), but in many systems
you'll still get some use out of other vacuums.
-- 
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)                         http://jim.nasby.net

In response to

pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2007-01-25 16:04:49
Subject: Re: [HACKERS] how to plan for vacuum?
Previous:From: Ray StellDate: 2007-01-25 13:47:03
Subject: Re: how to plan for vacuum?

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2007-01-25 16:02:03
Subject: Re: Access last inserted tuple info...
Previous:From: Joshua D. DrakeDate: 2007-01-25 15:52:01
Subject: Re: Recursive Queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group