Re: [PROPOSAL] VACUUM Progress Checker. - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id 20150731192939.GA2441@postgresql.org
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Fabrízio de Royes Mello
Date:
Subject: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Next
From: "Paragon Corporation"
Date:
Subject: Use of PRId64 with PostgreSQL functions