Re: [HACKERS] CLUSTER command progress monitor
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-12-18T21:01:59Z
Lists: pgsql-hackers
On 2017-Nov-21, Peter Geoghegan wrote: > On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > Progress reporting on sorts seems like a tricky problem to me, as I > > said before. In most cases, a sort is going to involve an initial > > stage where it reads all the input tuples and writes out quicksorted > > runs, and then a merge phase where it merges all the output tapes into > > a sorted result. There are some complexities; for example, if the > > number of tapes is really large, then we might need multiple merge > > phases, only the last of which will produce tuples. > > This would ordinarily be the point at which I'd say "but you're very > unlikely to require multiple passes for an external sort these days". > But I won't say that on this thread, because CLUSTER generally has > unusually wide tuples, and so is much more likely to be I/O bound, to > require multiple passes, etc. (I bet the v10 enhancements > disproportionately improved CLUSTER performance.) When the seqscan-and-sort strategy is used, we feed tuplesort with every tuple from the scan. Once that's completed, we call `performsort`, then retrieve tuples. If we see this in terms of tapes and merges, we can report the total number of each of those that we have completed. As far as I understand, we write one tape to completion, and only then start another one, right? Since there's no way to know how many tapes/merges are needed in total, it's not possible to compute a percentage of completion. That's seems okay -- we're just telling the user that progress is being made, and we only report facts not theory. Perhaps we can (also?) indicate disk I/O utilization, in terms of the number of blocks written by tuplesort. I suppose that in order to have tuplesort.c report progress, we would have to have some kind of API that tuplesort would invoke internally to indicate events such as "tape started/completed", "merge started/completed". One idea is to use a callback system; each tuplesort caller could optionally pass a callback to the "begin" function, for progress reporting purposes. Initially only cluster.c would use it, but I suppose eventually every tuplesort caller would want that. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix progress reporting of CLUSTER / VACUUM FULL
- 6212276e4343 13.0 landed
- da47e43dc32e 12.0 landed
-
Fix thinko when ending progress report for a backend
- f4b91a50e9e6 9.6.16 landed
- 4950f09e7ae2 10.11 landed
- af28744288b1 11.6 landed
- 4c3e750ab4b5 12.0 landed
- ae060a52b288 13.0 landed
-
Report progress of REINDEX operations
- 03f9e5cba0ee 12.0 cited
-
Add progress reporting for CLUSTER and VACUUM FULL.
- 6f97457e0ddd 12.0 landed
-
Un-hide most cascaded-drop details in regression test results.
- 940311e4bb32 12.0 cited
-
Fix memory leak in printtup.c.
- f2004f19ed9c 12.0 cited
-
Remove unused macro
- fb5806533f9f 12.0 cited