On Tue, Sep 15, 2026 at 12:10:54PM -0500, Sami Imseih wrote:
> But if we ever support parallel heap scan during VACUUM, what would
> heap_blks_total and heap_blks_scanned represent at that point? Would
> they remain command-level aggregate progress, or become per-worker
> progress?
My best reply for this set of questions is that I don't really have a
clear reply because I don't know what the future is made of, because
the choices of the progress fields are driven by the way the
implementations are done for parallelization. Here the choices are
based on how index cleanup phases are done in [auto]vacuum, so the
fields make sense, in the existing view, with one entry in the
progress view for each worker that's been spawned.
> My point is that the existing progress views have historically exposed
> command-level aggregate stats. Trying to also use them for per-worker
> stats in the same view does not seem right to me.
Perhaps so, but it does not mean that this cannot be overruled if
another reason justifies so. I'm seeing a reason here in terms of the
granularity of the data reported per worker: the index actually
processed by each worker, and the block area that's being browsed.
--
Michael
