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

Re: Deadline-Based Vacuum Delay

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deadline-Based Vacuum Delay
Date: 2006-12-30 06:48:36
Message-ID: 4550.1167461316@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Chris Browne <cbbrowne(at)acm(dot)org> writes:
> How you get the work to spread consistently across 6 hours is a
> challenge; personally, my preference would generally be to try to get
> the work done ASAP, so the goal seems a tad off to me...

I think the context for this is that you have an agreed-on maintenance
window, say extending from 2AM to 6AM local time, and you want to get
all your vacuuming done in that window without undue spikes in the
system load (because you do still have live users then, just not as many
as during prime time).  If there were a decent way to estimate the
amount of work to be done then it'd be possible to spread the work
fairly evenly across the window.  What I do not see is where you get
that estimate from --- especially since you probably have more than one
table to vacuum in your window.

The other problem is that "vacuum only during a maintenance window"
doesn't seem all that compelling a policy anyway.  We see a lot of
examples of tables that need to be vacuumed much more often than once
a day.  So I'd rather put effort into making sure that vacuum can be run
in the background even under high load, instead of designing around a
maintenance-window assumption.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-30 07:10:42
Subject: Re: TODO: GNU TLS
Previous:From: Jonah H. HarrisDate: 2006-12-30 05:49:19
Subject: Re: WITH support

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