On 2013-09-20 11:30:26 -0400, Robert Haas wrote:
> On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > The reason I suggested keeping track of the xids of unremovable tuples
> > is that the current logic doesn't handle that at all. We just
> > unconditionally set n_dead_tuples to zero after a vacuum even if not a
> > single row could actually be cleaned out. Which has the effect that we
> > will not start a vacuum until enough bloat (or after changing this, new
> > inserts) has collected to start vacuum anew. Which then will do twice
> > the work.
> >
> > Resetting n_dead_tuples to the actual remaining dead tuples wouldn't do
> > much good either - we would just immediately trigger a new vacuum the
> > next time we check, even if the xmin horizon is still the same.
>
> One idea would be to store the xmin we used for the vacuum somewhere.
> Could we make that part of the pgstats infrastructure? Or store it in
> a new pg_class column? Then we could avoid re-triggering until it
> advances. Or, maybe better, we could remember the oldest XID that we
> weren't able to remove due to xmin considerations and re-trigger when
> the horizon passes that point.
I suggested a slightly more complex variant of this upthread:
http://archives.postgresql.org/message-id/20130907053449.GE626072%40alap2.anarazel.de
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services