Re: autovacuum - Mailing list pgsql-hackers

From Chris Browne
Subject Re: autovacuum
Date
Msg-id 60fyn2luwn.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: autovacuum  (Chris Browne <cbbrowne@acm.org>)
List pgsql-hackers
tgl@sss.pgh.pa.us (Tom Lane) writes:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Hmm, yeah, sounds useful.  There's one implementation issue to notice
>> however, and it's that the autovacuum process dies and restarts for each
>> iteration, so there's no way for it to remember previous state unless
>> it's saved somewhere permanent, as the stats info is.
>
> I think you'd really need to remember the previous oldest XID on a
> per-table basis to get full traction out of the idea.  But weren't
> we thinking of tracking something isomorphic to this for purposes of
> minimizing anti-wraparound VACUUMs?

I think I'd like that even better :-).

In the Slony-I case, the tables being vacuumed are ones where the
deletion is taking place within the same thread, so that having one
XID is plenty enough because the only thing that should be touching
the tables is the cleanup thread, which is invoked every 10 minutes.
One XID is enough "protection" for that, as least as a reasonable
approximation.

Tracking just the one eldest XID is still quite likely to be
*reasonably* useful with autovacuum, assuming there isn't a by-table
option.  By-table would be better, though.
-- 
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"Politics  is not a  bad  profession.  If  you succeed there  are many
rewards, if you disgrace yourself you can always write a book."
-- Ronald Reagan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen
Next
From: Bruce Momjian
Date:
Subject: Re: A note about testing EXEC_BACKEND on recent Linuxen