Galy Lee <[EMAIL PROTECTED]> 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
> practices.
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
