Обсуждение: Request to have VACUUM ignore cost based limits

Hi,

Just had a situation where a database was reloaded and needed to
be vacuum analyzed before it could be used.  I believe the
cost-based vacuum delay slowed this down considerably.
(I could be wrong, but there was darn little load on the
system...)

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

Regards,

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

P.S. Thought I'd post here rather than to the deveoper's
list to get some general feedback.

"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?

            regards, tom lane

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

"Karl O. Pinc" <kop@meme.com> writes:
> On 02/08/2006 09:46:46 PM, Tom Lane wrote:
>> What's wrong with SET?

> For my purposes at the moment, probably nothing.
> But isn't SET server wide?

No.  Perhaps you need to read
http://www.postgresql.org/docs/8.1/static/runtime-config.html#CONFIG-SETTING

            regards, tom lane

On 02/09/2006 12:19:39 AM, Tom Lane wrote:
> "Karl O. Pinc" <kop@meme.com> writes:
> > But isn't SET server wide?
>
> No.  Perhaps you need to read
> http://www.postgresql.org/docs/8.1/static/runtime-config.html#CONFIG-SETTING

Yes, I do.  Thanks.  (Probably a sign it's time to read
the whole manual again.)

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