On Wed, 18 Feb 2026 at 06:35, Nathan Bossart <[email protected]> wrote: > > On Tue, Feb 17, 2026 at 04:12:58PM +0530, VASUKI M wrote: > > I would greatly appreciate thoughts before working on a prototype patch. > > At the risk of substantially expanding the scope of these patches, I wonder > if a better long-term approach would be to first centralize the > autovacuum/autoanalyze prioritization code and share it via a system view > that vacuumdb could use in place of the giant query for > --missing-stats-only. That would also give users visibility into > auto{vacuum,analyze}'s decisions. TBH I'm not totally sold on the idea of > giving ANALYZE more options for this stuff, if for no other reason than I'm > not really following the concrete use-cases, but I wouldn't say I'm > mortally opposed to it.
Yeah, I'm not at all excited about adding options to ANALYZE for this sort of thing either. I agree with the VIEW idea. If we had the vacuum scoring stuff, I imagined it'd be useful to have a view that lists tables and their vacuum/analyze score. If people want to script this sort of thing then querying that view and running analyze on the returned tables seems simple enough. I imagined a common thing that people might want to do would be freeze tables that have a freeze age somewhere close to autovacuum_freeze_max_age while off-peak so that autovacuum doesn't trigger for that on-peak. If we allow ANALYZE to have the proposed option, then we're opening a can of worms for various other possible requirements for similar options in the VACUUM command. I also agree that vacuumdb could be a good place to code this up. David
