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 predictions. 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: http://www.postgresql.org/mailpref/pgsql-hackers
