Thread: 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