On Tue, 2025-08-19 at 23:40 +0900, Fujii Masao wrote: > > > --- a/doc/src/sgml/ref/vacuumdb.sgml > > > +++ b/doc/src/sgml/ref/vacuumdb.sgml > > > @@ -397,6 +397,15 @@ PostgreSQL documentation > > > Multiple tables can be vacuumed by writing multiple > > > <option>-t</option> switches. > > > </para> > > > + <para> > > > + If no tables are specified with the <option>--table</option> > > > option, > > > + <application>vacuumdb</application> will clean all regular tables > > > + and materialized views in the connected database. > > > + If <option>--analyze-only</option> or > > > + <option>--analyze-in-stages</option> is also specified, > > > + it will analyze all regular tables, partitioned tables, > > > + and materialized views (but not foreign tables). > > > + </para> > > > > I suggest replacing "clean" with "process", since VACUUM does so much more > > than > > clean up dead tuples. > > I see your point. However, since the vacuumdb docs already use "clean" > in several places, I think it's better to keep using "clean" here > for consistency. Thought?
Works for me; I didn't consider that. > > Concerning backpatching, I voted against, but I suggest that this be > > backpatched > > to v18. I don't feel very strongly about it though. > > As for back-patching, I failed to find a strong reason to apply this change > to v18 over the many other patches that could not be committed before > the feature freeze... Of course if there's broad support for back-patching, > we can certainly revisit it. But for now I'm thinking to commit the patch > to master. I don't have a strong reason either - my reasoning was that the change is small and unlikely to introduce a bug, and that it would be nice to get more accurate statistics on partitioned tables after "pg_upgrade" a year earlier. But I won't object if the patch is only in v19. Yours, Laurenz Albe
