Re: pg_autovacuum next steps

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 backend stuff.

The base should be the standard backend with different "main loop" that
will instead socket checks some shared information about tables and
calls directly vacuum stuff. In this case you can omit work with
connections, parser etc.

I thought about it in last days and I found perfect Tom's idea about
FSM 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 the tuple 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 priority to 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(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/