Hi, The discussion makes sense to me.
Just to add one variant for consideration: "Emits detailed information about vacuum activity for each table in the form of INFO and DETAIL messages." Thanks. On Tue, Apr 14, 2026 at 6:29 AM David G. Johnston < [email protected]> wrote: > On Mon, Apr 13, 2026 at 2:28 PM Maciek Sakrejda <[email protected]> > wrote: > >> On Tue, Apr 7, 2026 at 6:57 PM Shinya Kato <[email protected]> >> wrote: >> > On Mon, Apr 6, 2026, 14:17 David G. Johnston < >> [email protected]> wrote: >> >> >> >> How about something like: >> >> “Enables sending an INFO message to the client (and server log) as >> each table is processed. This message contains: etc…” >> >> >> >> And then let’s tell the user what info they are getting and what it >> means (where necessary). >> >> >> >> I concur being specific about when these messages arrive, and IMO >> where, should be specified. But losing the detail of “report” is not good; >> but not sure why we are being vague so suggest we just go all-in on >> specificity. >> > >> > Thank you for the suggestion. I'd prefer to keep this patch focused; >> since the verbose output of both commands is subject to change, listing >> every individual field in the documentation would require frequent updates. >> > >> > I believe the current "Outputs" section is intentionally kept simple to >> minimize maintenance overhead. While expanding it might be a worthwhile >> follow-up, it probably deserves its own dedicated discussion. >> >> +1, listing output details is signing up for busywork. > > > Given how expansive and thorough our documentation is, and the fact this > is user-facing output, I'm not seeing why this gets a pass on the > documentation requirement. That said, I concur this patch needn't be > responsible for dealing with that - I'm not even sure whether trying to do > that on the vacuum/analyze pages is even the correct choice since at least > some of what is output is object-specific and not generic to vacuum > itself. Though stuff like timings are. Even if we want to leave ourselves > the "it's undocumented so it can be changed at will" clause we can simply > write that in. > > maybe something >> along these lines: >> >> "Prints detailed stats at <literal>INFO</literal> level for each table >> as it is processed." >> >> > I really don't like the word "Print" here. What the client decides to do > with the INFO message is up to them - the interface to document for the > server is simply sending the message and its details. > > I was apparently mistaken about this info showing in the server log file > though. > > So that leaves me with suggesting: > > "Enables the sending of a detailed INFO message to the client after each > table is processed." > > David J. > >
