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
