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.

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

      - 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

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.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to