Re: VACUUM DELAY

From: "Scott Marlowe" <smarlowe(at)qwest(dot)net>
To: "Gaetano Mendola" <mendola(at)bigfoot(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM DELAY
Date: 2004-08-09 13:01:16
Message-ID: 1092056476.27166.315.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2004-08-09 at 05:19, Gaetano Mendola wrote:
> Hi all,
> I have seen the big debat about to have the delay
> off or on by default.
>
> Why not enable it by default and introduce a new
> parameter to vacuum command itself ? Something like:
>
>
> VACUUM .... WITH DELAY 100;
>
>
> this will permit to change easilly the delay in the maintainance
> scripts.

The problem, I believe, is that any delay at all results in a VERY slow
vacuum run (like 3 to 5 times slower) and for some people, this will be
such unexpected behaviour they may believe postgresql is broken, or just
want the older, faster vacuum, especially in a development environment.
Imagine an increase from 1 to 5 minutes on an otherwise duplicate
database from a 7.4 machine.

I'll personally be running the delay and autovacuum on any machine I'll
be running, and I think once the autovacuum is integrated, it might make
sense to have a vacuum command just toss an entry in a que saying
"vacuum this table next scheduled run" and return immediately with a
NOTICE: vacuum (on tablex) scheduled.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera Munoz 2004-08-09 13:01:26 Re: Analyze using savepoints?
Previous Message Reinoud van Leeuwen 2004-08-09 12:49:40 Re: Postgres development model (was Re: CVS comment)