Re: Resumable vacuum proposal and design overview

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