From: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Request to have VACUUM ignore cost based limits |
Date: | 2006-02-09 04:27:30 |
Message-ID: | 1139459250l.20096l.33l@mofo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 02/08/2006 09:46:46 PM, Tom Lane wrote:
> "Karl O. Pinc" <kop(at)meme(dot)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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From | Date | Subject | |
---|---|---|---|
Next Message | surabhi.ahuja | 2006-02-09 04:54:38 | Re: loading pg_description ... FATAL: duplicate key violates unique constraint "pg_description_o_c_o_index" |
Previous Message | Bruce Momjian | 2006-02-09 03:57:20 | Re: Sequences/defaults and pg_dump |