Skip site navigation (1) Skip section navigation (2)

Re: autovacuum next steps, take 2

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2007-02-27 03:51:02
Subject: Re: autovacuum next steps, take 2
Previous:From: Tom LaneDate: 2007-02-27 03:43:34
Subject: Re: autovacuum next steps, take 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group