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
signature.asc
Description: PGP signature
