Hi, On Wed, Sep 30, 2026 at 6:55 PM Michael Paquier <[email protected]> wrote: > > I've looked at v7, and my main comment is that this is bloated in > terms of docs and comments. My hands-on is leading me to the attached > result, that reduces the docs to actually explain what these new > counters do, and only that, including your note at the bottom about > the workers and the relevant fields. :D
Agreed. Simplifying the wording and dropping the code-level details, such as how and when a worker shows the initializing phase, is nice. Also, dropping the sentence about the pg_read_all_stats role is fine too, since monitoring.sgml already covers that at the top. > Then, I don't really have a lot of feelings for v7-0002. Even if all > the paths set the progress flag to true in the backend core code, > I think that there is an out-of-core argument in favor of keeping it, > as some code out there may want to control if progress should show up > or not. And I suspect that we will need it at some point.. Agreed. A non-core index AM might want to use it. > During parallel index vacuuming or cleanup, the leader and each active > worker report separate rows, all sharing the same > <structfield>relid</structfield>. Worker rows exist only while the worker is > performing parallel vacuum work. The repeated use of "worker" here reads a bit hard to follow for me. "During parallel vacuum" already implies the workers are running, and per the docs today, parallel vacuum applies to index vacuuming (I don't see "parallel index vacuum" or "cleanup" used elsewhere in the docs, though they do appear in the code), so what v8 has reads fine to me. Thanks, Michael, for attaching the v8 patch. It looks good to me as-is. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
