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

Re: 7.4RC1 planned for Monday

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.4RC1 planned for Monday
Date: 2003-10-31 18:18:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 30 Oct 2003, Joshua D. Drake wrote:

> If I understood correctly, Josh was complaining about VACUUM sucking too
> >much of his disk bandwidth.  autovacuum wouldn't help that --- in fact
> >would likely make it worse, since a cron-driven vacuum script can at
> >least be scheduled for low-load times of day.  autovacuum is likely to
> >kick in at the least convenient times.
> >
> >  
> >
> Exactly!

Wait a minute, I thought the problem was that vacuums were happening too 
far apart, therefore taking too long, and may have been full, no?

If the autovacuum daemon causes a lazy vacuum to run on only the busiest 
(i.e. most updated) tables, then it is likely to only take a few minutes 
to run, instead of hours, plus you can try to keep things steady state.  
I.e. no more than x% or so dead tuples in a table at any given time, and 
they all get reused by fsm / lazy vacuum.

So, have you TESTED the autovacuum daemon with your load, and set it to 
run every 5 minutes?  Keep in mind, it won't actually vacuum every table 
every 5 minutes, it'll just check the stats to see which ones have updated 
a fair bit and vacuum those, and they're lazy vacuums.  I've found it to 
be a win.  If you haven't tested it and dismissed it out of hand, then you 
should really give it a try to see if it can be configured to provide good 
performance and behavior.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-10-31 19:07:01
Subject: Re: Experimental patch for inter-page delay in VACUUM
Previous:From: Stephan SzaboDate: 2003-10-31 18:15:51
Subject: Re: 7.4RC1 planned for Monday

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