On Mon, Aug 18, 2025 at 3:40 PM Laurenz Albe <laurenz.a...@cybertec.at> wrote: > > On Mon, 2025-08-18 at 11:38 +0900, Fujii Masao wrote: > > Thanks! So I've updated the patch based on my earlier comments. > > Unless there are objections, I'll commit the attached version to master > > only. > > I am fine with your patch.
Thanks for the review! > One suggestion: > > > --- 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? > 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. Regards, -- Fujii Masao
