Re: Deadline-Based Vacuum Delay

systemguards(at)gmail(dot)com ("Jaime Casanova") writes:
> On 12/28/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp> writes:
>> > So I am thinking another way to perform vacuum. For example vacuum can
>> > be refined in a maintenance time frame like "VACUUM IN 6 HOURS", and
>> > then vacuum operation will be performed within the window. The delay
>> > time is adjusted internally to spread the disk I/O over the time frame.
>>
>> And you will manage that how? The total amount of work to be done is
>> quite unpredictable.
>
> specially for something you already can do with cron (*nix) or job
> scheduler (windows)

That seems like a nonsequitor here...

Using cron to try to "make vacuums spread over 6 hours" seems to me
like an attempt to try to do that in as terrible a way possible.

If you're trying to spread work over time, you need to use something
that actively monitors the results, as opposed to a tool that is
entirely "fire and forget" (and perhaps forget to work), like cron.

It seems to me that the answer is much more along the lines of making
a greatly more intelligent autovacuum. Something offering:
- Queueing work (e.g. - in this case, we want to schedule a vacuum
of "everything")
- Processing that work; perhaps sometimes with multiple threads to
do multiple vacuums
- Perhaps using time estimates to determine any vacuum delay
GUC values to be applied

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...
--
let name="cbbrowne" and tld="linuxdatabases.info" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/x.html
The human race will decree from time to time: "There is something at
which it is absolutely forbidden to laugh."
-- Nietzche on Common Lisp