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
