Re: [HACKERS] CLUSTER command progress monitor
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>, Dmitry Dolgov <9erthalion6@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Jeff Janes <jeff.janes@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2019-03-06T01:03:38Z
Lists: pgsql-hackers
On 2019-Mar-04, Robert Haas wrote: > On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada > <yamada.tatsuro@lab.ntt.co.jp> wrote: > > === Discussion points === > > > > - Progress counter for "3. sorting tuples" phase > > - Should we add pgstat_progress_update_param() in tuplesort.c like a > > "trace_sort"? > > Thanks to Peter Geoghegan for the useful advice! > > How would we avoid an abstraction violation? The theory embodied in my patch at https://postgr.es/m/20190304204607.GA15946@alvherre.pgsql is that we don't; tuplesort.c functions (index.c's IndexBuildHeapScan in my case) would get a boolean parameter to indicate whether to update some params or not -- the param number(s) to update are supposed to be generic in the sense that it's not part of any individual command's implementation (PROGRESS_SCAN_BLOCKS_DONE for what you call "blks scanned", PROGRESS_SCAN_BLOCKS_TOTAL for "blks total"), but rather defined by the "progress update provider" (index.c or tuplesort.c). One, err, small issue with that idea is that we need the param numbers not to conflict for any "progress update providers" that are to be used simultaneously by any command. -- Á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