| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com> |
| Subject: | Re: autovacuum next steps, take 2 |
| Date: | 2007-02-27 03:48:49 |
| Message-ID: | 10387.1172548129@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> That does sounds simpler. Is chunk-at-a-time a realistic option for 8.3?
It seems fairly trivial to me to have a scheme where you do one
fill-workmem-and-scan-indexes cycle per invocation, and store the
next-heap-page-to-scan in some handy place (new pg_class column updated
along with relpages/reltuples, likely). Galy is off in left field with
some far more complex ideas :-( but I don't see that there's all that
much needed to support this behavior ... especially if we don't expose
it to the SQL level but only support it for autovac's use. Then we're
not making any big commitment to support the behavior forever.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew T. O'Connor | 2007-02-27 03:51:02 | Re: autovacuum next steps, take 2 |
| Previous Message | Tom Lane | 2007-02-27 03:43:34 | Re: autovacuum next steps, take 2 |