Re: Request to have VACUUM ignore cost based limits - Mailing list pgsql-general

From Karl O. Pinc
Subject Re: Request to have VACUUM ignore cost based limits
Date
Msg-id 1139459250l.20096l.33l@mofo
Whole thread Raw
In response to Re: Request to have VACUUM ignore cost based limits  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Request to have VACUUM ignore cost based limits  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 02/08/2006 09:46:46 PM, Tom Lane wrote:
> "Karl O. Pinc" <kop@meme.com> writes:
> > It would have been nice to have an option to SQL's VACUUM that would
> > ignore the cost-based delays so as to bring that database back
> > to life as rapidly as possible.  (Likewise the vacuumdb shell
> > command.)
>
> What's wrong with SET?

For my purposes at the moment, probably nothing.
But isn't SET server wide?  With autovacuum turned
on I wouldn't want other vacuums affected.  I'd
want to give a single, important, vacuum process
"first class" status and relegate all the other
vacuums to the background where they belong.
(Especially if SET did not change the operation
of already running vacuum processes, something
I'm unclear on in my present foggy brain state.
(Are the docs clear?)  Wouldn't want
to get bitten by an inopportune automatic vacuum
of a large table at the wrong time.)


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein


pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Sequences/defaults and pg_dump
Next
From: "surabhi.ahuja"
Date:
Subject: Re: loading pg_description ... FATAL: duplicate key violates unique constraint "pg_description_o_c_o_index"