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  <[EMAIL PROTECTED]>
 http://home.zf.jcu.cz/~zakkr/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to