Re: [PERFORM] encouraging index-only scans
От | Andres Freund |
---|---|
Тема | Re: [PERFORM] encouraging index-only scans |
Дата | |
Msg-id | 20130920155133.GB12763@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PERFORM] encouraging index-only scans (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PERFORM] encouraging index-only scans
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: