On Tue, Feb 24, 2026 at 08:19:55AM -0600, Sami Imseih wrote:
> But from a high-level, I am not sure how providing a VIEW or functions in
> which users will be required to script out the ANALYZE commands to run is
> better than providing ANALYZE options? the difference is putting the
> burden on the user to come up with the SQL script vs a simple ANALYZE
> option. IMO, the latter is more appealing from a user perspective.
My principle objection isn't with the option itself, it's that _just_
adding the option papers over the current state of affairs without taking
the opportunity to do a bunch of really useful centralization/refactoring.
By exposing the auto{vacuum,analyze} prioritization code and building off
that, we get a consistent picture wherever it is needed (e.g.,
auto{vacuum,analyze}, vacuumdb, monitoring tools, custom scripts, and any
new VACUUM/ANALYZE options) without having to reinvent the wheel each time.
Sure, we could have vacuumdb just use MISSING_STATS_ONLY for every command
in --missing-stats-only mode, but that seems like a lot of overhead, and we
still aren't helping with observability (which I expect to become even more
important as autovacuum's prioritization code evolves).
I'm admittedly waving my hands a bit here, but in any case, I think this is
an opportunity to do a bunch of super useful improvements that will have
much bigger benefits down the road.
--
nathan
