From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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 19:29:39 |
Message-ID: | 20150731192939.GA2441@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Paragon Corporation | 2015-07-31 19:43:07 | Use of PRId64 with PostgreSQL functions |
Previous Message | Fabrízio de Royes Mello | 2015-07-31 19:12:14 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |