Re: Resumable vacuum proposal and design overview

Simon Riggs wrote:
>>old dead tuple list. If the system manages the dead tuple list we may
>>need to keep such files around for long periods, which doesn't sound
>>great either.

The system manages such files. The files are kept in location like
$PGDATA/pg_vacuum. They are removed when CLUSTER, DROP TABLE, ALTER
TABLE, VACUUM etc, changes the physical layout of heap. I think this
is a reasonable way.

>>ISTM simpler to make the optional stop/restart point be after one full
>>cycle of cleaning, so exactly at the point where we discard one tuple
>>list and we move on the next.

I just summary your ideas here:

　　Where to stop?
　　　- stop after one full cycle of cleaning finished

How to stop?
　　　-　When stopping at step 1, goes straight to step 2 and step 3
to clean the dead tuples harvested so far.
- When stopping at step 2 or step 3, vacuum ignores the
stop request to finish all of the steps.

Merit:
- For it does not require external file to store dead
tuple list, it can simplify the implementation.

Demerit:
- The time length between stop request generated and vacuum
stopping is still quit unpredictable. (Considering that
sometimes step 2 takes 2 or 3 hours, step 3 may take the
same time with step 1)
- It is difficult to refined vacuum in maintenance window
frame.

The point in here is that *how long* can we accept for vacuum stopping.

For example, there is one table:
- The table is a hundreds GBs table.
- It takes 4-8 hours to vacuum such a large table.
- Enabling cost-based delay may make it last for 24 hours.
- It can be vacuumed during night time for 2-4 hours.

It is true there is no such restrict requirement that vacuum
need to be interrupt immediately, but it should be stopped in an
*predictable way*. In the above example, if we have to wait for the end
of one full cycle of cleaning, it may take up to 8 hours for vacuum to
stop after it has received stop request. This seems quit unacceptable.