Re: [PROPOSAL] VACUUM Progress Checker.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Rahila Syed <rahilasyed90(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Date: 2015-07-31 18:54:39
Message-ID: CA+TgmoZCiNRoS=kjhFCHpMkoq3sjoH-ejJp6WSPGT3RmwLrrKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 31, 2015 at 2:21 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2015-07-31 18:55:24 Re: Planner debug views
Previous Message Robert Haas 2015-07-31 18:48:55 Re: Transactions involving multiple postgres foreign servers