Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id 20150731192939.GA2441@postgresql.org
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas wrote:
> On Fri, Jul 31, 2015 at 2:21 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > I think the only way to produce usable estimates is to report more than
> > one number.  And in the particular case of lazy vacuuming, ISTM the way
> > to do it is to consider heap scanning as one phase, index cleanup as
> > another phase; these two phases can be interleaved.  And there's a final
> > heap scan which is a third phase, which can only run after phases one
> > and two are complete.
> 
> That's not really right.  There's a phase three for each phase two.
> 
> Put in terms of the code, what we're calling phase one is
> lazy_scan_heap(), which prunes all pages, sets hint bits, collects
> dead TIDs, and maybe marks the page all-visible.
> 
> When lazy_scan_heap() fills up maintenance_work_mem, or when it
> reaches the end of the heap, it does phase two, which is
> lazy_vacuum_index(), and phase three, which is lazy_vacuum_heap().
> Phase one - lazy_scan_heap() - then keeps going from where it left
> off.

Hmm, you're right.  I don't think it changes the essence of what I
suggest, though.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Следующее
От: "Paragon Corporation"
Дата:
Сообщение: Use of PRId64 with PostgreSQL functions