One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
think it has to be done in four stages:
o move it into the backend and have it start/stop automatically
o move the autovacuum configuration parameters into postgresql.conf
o modify the code to use the backend API for error recovery
o modify the code to use the backend API utilities, like hashes
Who would like to get started on this? It seems pretty straight-forward.
---------------------------------------------------------------------------
Tom Lane wrote:
> "Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> > Honestly, I'd prefer to see pg_autovacuum improved to do O(n) rather
> > than O(n^2) table activity. At this point, though, I'm probably not
> > too likely to have much time to hack pg_autovacuum before 8.1 is
> > released, although if it doesn't become integrated by beta feature
> > freeze, I might give it a shot.
>
> This would be vastly easier to fix if the code were integrated into the
> backend first. In the backend environment you could just keep the info
> in a dynahash.c hashtable instead of in a linear list. On the client
> side, you have to roll your own hashing (or adapt dynahash to life
> outside the backend environment).
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
