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

From Alvaro Herrera
Subject Re: [PROPOSAL] VACUUM Progress Checker.
Date
Msg-id 20150810165017.GE2441@postgresql.org
Whole thread Raw
In response to Re: [PROPOSAL] VACUUM Progress Checker.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [PROPOSAL] VACUUM Progress Checker.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: [PROPOSAL] VACUUM Progress Checker.  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Masahiko Sawada wrote:

> This topic may have been already discussed but, why don't we use just
> total scanned pages and total pages?

Because those numbers don't extrapolate nicely.  If the density of dead
tuples is irregular across the table, such absolute numbers might be
completely meaningless: you could scan 90% of the table without seeing
any index scan, and then at the final 10% be hit by many index scans
cleaning dead tuples.  Thus you would see progress go up to 90% very
quickly and then take hours to have it go to 91%.  (Additionally, and a
comparatively minor point: since you don't know how many index scans are
going to happen, there's no way to know the total number of blocks
scanned, unless you don't count index blocks at all, and then the
numbers become a lie.)

If you instead track number of heap pages separately from index pages,
and indicate how many index scans have taken place, you have a chance of
actually figuring out how many heap pages are left to scan and how many
more index scans will occur.

> The mechanism of VACUUM is complicated a bit today,

Understatement of the week ...

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Geoff Winkless
Date:
Subject: Re: Precedence of standard comparison operators
Next
From: Tom Lane
Date:
Subject: Re: WIP: Rework access method interface