Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane wrote:
>> ... or set a flag to stop at the next cycle-completion point.
> The extra cost to clean indexes may prevent this approach to work in
Huh? There is no extra cost in what I suggested; it'll perform
exactly the same number of index scans that it would do anyway.
>> Perhaps a more useful answer to the problem of using a
>> defined maintenance window is to allow VACUUM to respond to changes in
>> the vacuum cost delay settings on-the-fly.
> This is a good idea! Itagaki also have talked about exactly the same
> idea to me yesterday.
> But if we change the parameters on-fly to make vacuum less aggressive,
> my concern is that: is there any potential problems to run vacuum in
> several days?
If the table is sufficiently large, that could happen anyway. The
issues here, I think, are to not eat resources that foreground processes
need (which vacuum-cost-delay addresses) and to not block vacuuming of
hot-update tables (which can be addressed by allowing multiple autovac
workers). So I'm not really convinced that being able to stop a table
vacuum halfway is critical.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: John Bartlett||Date: 2007-02-28 04:14:54|
|Subject: Re: - WIP Patch Updatable Cursor|
|Previous:||From: Jonah H. Harris||Date: 2007-02-28 03:43:53|
|Subject: Re: COMMIT NOWAIT Performance Option|