Skip site navigation (1) Skip section navigation (2)

Re: Resumable vacuum proposal and design overview

From: Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resumable vacuum proposal and design overview
Date: 2007-02-27 02:44:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2007-02-27 02:44:34
Subject: Re: COMMIT NOWAIT Performance Option
Previous:From: Jim C. NasbyDate: 2007-02-27 02:40:52
Subject: Re: autovacuum next steps, take 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group