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
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 |