From: | tomas(at)tuxteam(dot)de |
---|---|
To: | Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Resumable vacuum proposal and design overview |
Date: | 2007-02-26 10:45:56 |
Message-ID: | 20070226104556.GA29279@www.trapp.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Feb 26, 2007 at 06:21:50PM +0900, Galy Lee wrote:
> Hi
>
> We are developing a new feature for vacuum, here is a brief overview
> about it.
[...]
> Concurrent vacuum mainly has the following steps to vacuum a table:
>
> 1. scan heap to collect dead tuple list
> 2. (if the table has indexes) scan and sweep indexes
> 3. sweep dead tuples collected in step 1
> 4. perform additional index cleanup operation
> 5. (if a certain of free space found) truncate table
> 6. register free space to FSM
> 7. update statistics of the table
[...]
> This implementation accepts stop request at *blocks level* in step 1-4.
WARNING: I don't really know what I'm talking about -- but considering
that vaccuming a large table across several "maintainance windows" is
one of the envisioned scenarios, it might make sense to try to update
the statistics (i.e. to do partially step 7) on each partial run.
Otherwise the table's stats might wander off for quite long times?
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFF4rpkBcgs9XrR2kYRAoZ1AJwMOSpxlbVSYtPKitEhjem5Jrax7gCeMokx
8DLhqBv9QrtGIDPKOKUi9qw=
=WIiA
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-02-26 11:06:52 | Bitmap index stuff |
Previous Message | Simon Riggs | 2007-02-26 10:20:09 | Re: Resumable vacuum proposal and design overview |