On 2013-09-20 11:30:26 -0400, Robert Haas wrote: > On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
