| From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:53:34 |
| Message-ID: | 45E3AB3E.4020600@zeut.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "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.
Well, if we can make it happen soon, it might be the best thing for
autovacuum.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-02-27 04:04:07 | Re: COMMIT NOWAIT Performance Option |
| Previous Message | Matthew T. O'Connor | 2007-02-27 03:51:02 | Re: autovacuum next steps, take 2 |