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.
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) |