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,
DROPTABLE, 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.
(Consideringthat sometimes step 2 takes 2 or 3 hours, step 3 may take the same time with step 1) -
Itis 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 endof one full cycle of cleaning, it may take up to
8hours for vacuum to
stop after it has received stop request. This seems quit unacceptable.
