On Mon, Mar 22, 2004 at 02:35:37AM -0500, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there. A while ago, Bruce offered to help me with any backend
> > > > issues I might have, so perhaps with a little help I can take a run at
> > > > it.
> > >
> > > I'd be happy to help you out.
> >
> > Agreed.
>
> Ok, thanks for the offer to help, but I think I understated things above
> when I said I'll need a "little" help :-)
>
> I have a few big picture questions. Once pg_autovacuum is launched as a
> postmaster sub-process, what changes?
All. It's important do it as backend process. Because libpq has very,very limited and slow resources for work with
backendstuff.The base should be the standard backend with different "main loop" thatwill instead socket checks some
shared information about tables andcalls directly vacuum stuff. In this case you can omit work withconnections,
parseretc.
I thought about it in last days and I found perfect Tom's idea aboutFSM tables usage:
What I had in the back of my mind was: each backend counts attempted insertions and deletions in
its relcache entries (an update adds to both counts). At transaction commit or abort, we know which of
these two counts represents the number of dead tuples added to each relation, so while we scan the relcache for
post-xact cleanup (which we will be doing anyway) we can transfer the correct count into the
shared FSM entry for the relation. This gives us a reasonably accurate count in shared memory of all
thetuple obsoletions since bootup, at least for heavily-used tables. (The FSM might choose to forget about
lightly-used tables.) The auto vacuumer could look at the FSM numbers to decide which tables are highest
priorityto vacuum. (2002-09-03 08:10:32)
I looked at the code and I think extend FSM tables will pretty simple,but I unsure how relcache counters Tom thought.
Tom?
Karel
-- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/