> On Wed, Aug 19, 2026 at 07:37:00PM -0700, Bharath Rupireddy wrote: > > I don't think a separate view is the right approach at least for two > > reasons. One, to know the progress of a vacuum one has to query two > > views and relate them. Two, since the leader itself participates in > > vacuuming indexes alongside workers (and will also for parallel heap > > vacuum), splitting the same command's progress into two views adds > > complexity. Keeping everything in a single view with one row per > > worker (as discussed upthread) is simpler. Some fields would be null > > on worker rows, but documenting this should be sufficient. That said, > > I'm open to hear more thoughts on this. > > Having a single progress view feels like the natural approach here, > for both the leader and the workers. The leader triggers the > existence of the workers, but both leader and workers may finish by > doing the same job as there could be usually little meaning for a > leader to stand idle, waiting for all the workers to do the work. > Such choices are implementation-agnostic, of course; we should not > lock ourselves.
This sounds to me that we are ok with breaking the principle design of the progress views, at least how I understand it, which is that we only have one row associated with the backend from which the user issued command. Background workers that are started as a result of that command, and are transient during the life of the command, don’t fit into that. Also, If we include workers in a separate row, we will need to mix stats that are aggregate of the entire command with stats that are specific to the work that leader done on its own. what would heap_blks_* refer to in this case? The aggregate of heap blocks accessed by the leader and workers -or— just the blocks accessed by the leader? I think monitoring tools/users consuming this view can better deal with the separation of worker level details ( worker here is also the leader ) in one view and the aggregate/high level information in the separate existing view(s) much better than having to deal with documented caveats about what the stats mean. -- Sami
