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

From Robert Haas
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id CA+TgmoZCiNRoS=kjhFCHpMkoq3sjoH-ejJp6WSPGT3RmwLrrKw@mail.gmail.com
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PROPOSAL] VACUUM Progress Checker.
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Transactions involving multiple postgres foreign servers
Next
From: Qingqing Zhou
Date:
Subject: Re: Planner debug views