On Fri, Sep 6, 2019 at 5:11 AM Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 6, 2019 at 1:44 AM Michael Paquier <mich...@paquier.xyz> wrote: > > I don't see exactly why we could not switch to a fixed number of > > slots, say 8, with one code path to start a progress which adds an > > extra report on the stack, one to remove one entry from the stack, and > > a new one to reset the whole thing for a backend. This would not need > > much restructuration of course. > > You could do that, but I don't think it's probably that great of an > idea. Now you've built something which is significantly more complex > than the original design of this feature, but still not good enough to > report on the progress of a query tree. I tend to think we should > confine ourselves to the progress reporting that can reasonably be > done within the current infrastructure until somebody invents a really > general mechanism that can handle, essentially, an EXPLAIN-on-the-fly > of a current query tree.
+1. Let's not complicate the progress reporting infrastructure for an uncertain benefit. CLUSTER/VACUUM FULL is fundamentally an awkward utility command to target with progress reporting infrastructure. I think that it's okay to redefine how progress reporting works with CLUSTER now, in order to fix the REINDEX/CLUSTER state clobbering bug. -- Peter Geoghegan
