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: | 45E39B0C.2080306@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2007-02-27 02:44:34 | Re: COMMIT NOWAIT Performance Option |
Previous Message | Jim C. Nasby | 2007-02-27 02:40:52 | Re: autovacuum next steps, take 2 |