| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>, "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RFC: changing autovacuum_naptime semantics |
| Date: | 2007-03-09 12:35:02 |
| Message-ID: | 87k5xq4mtl.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Er, why not just finish out the scan at the reduced I/O rate? Any sort
> of "abort" behavior is going to create net inefficiency, eg doing an
> index scan to remove only a few tuples. ISTM that the vacuum ought to
> just continue along its existing path at a slower I/O rate.
I think the main motivation to abort a vacuum scan is so we can switch to some
more urgent scan. So if in the middle of a 1-hour long vacuum of some big
warehouse table we realize that a small hot table is long overdue for a vacuum
we want to be able to remove the tuples we've found so far, switch to the hot
table, and when we don't have more urgent tables to vacuum resume the large
warehouse table vacuum.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2007-03-09 12:40:06 | Re: Auto creation of Partitions |
| Previous Message | Simon Riggs | 2007-03-09 12:31:07 | Re: CLUSTER and MVCC |