On Fri, Mar 10, 2017 at 2:57 PM, Jim Nasby <jim.na...@openscg.com> wrote:
> Oh, I wasn't suggesting a single SRF for everything. Hopefully users will
> eventually figure out a good formula to drive a "progress bar" for each type
> of monitor, which is what you really want anyway (at least 99% of the time).
> If we got there we could have a single view that gave the % complete for
> every command that was providing feedback. If someone wanted details they
> could hit the individual SRF.

So, the point, at least with the VACUUM progress indicator and perhaps
here also, is that we really can't just give a single measure of
progress -- we are 58.32% done.  That's almost impossible to estimate
accurately.  For example, consider VACUUM.  maintenance_work_mem is
69% used, and we are 74% done vacuuming the table.  What percentage
done are we?  Well, it depends.  If the latter part of the table has
exactly the same density of dead tuples we've already witnessed, we
will need only one index vac pass, but there is a good chance that
there's more activity toward the tail end of the table and we will
need two index vac passes.  If the table has several large indexes,
that's a big difference, so if we guess wrong about whether we're
going to run out of memory, we will be way off in estimating overall
progress.  That's why the vacuum progress checker reports the facts we
actually know -- like how many blocks of the relation we've scanned,
and how many dead tuples we've accumulated so far, and how many dead
tuples we are able to store before triggering index vacuuming --
rather than just a percentage.  You can try to derive a percentage
from that if you want, and you can use any formula you like to derive
that, but what the system reports are straight-up facts, not

I don't really want to get into the prediction business.  The in-core
progress reporting structure can spit out enough data for people to
write queries or tools that attempt to predict stuff, and *maybe*
someday somebody will write one of those tools that is enough unlike
https://xkcd.com/612/ that we'll feel moved to put it in core.  But my
guess is most likely not.  It's easy to get the easy cases right in
such a prediction tool, but AFAICS getting the hard cases right
requires a crystal ball.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to