Re: [PROPOSAL] VACUUM Progress Checker.

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

In response to

Browse pgsql-hackers by date

  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 ( .. );