Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sami Imseih <samimseih(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>
Subject: Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds
Date: 2026-02-17 23:12:38
Message-ID: CAApHDvpDB02ifo_VSDhEkAaRcRGTxH=jZKb__vG9t9v4E4ncqw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 18 Feb 2026 at 06:35, Nathan Bossart <nathandbossart(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-02-17 23:59:12 Re: [PATCH] Add last_executed timestamp to pg_stat_statements
Previous Message Andres Freund 2026-02-17 23:11:10 Re: add assertion for palloc in signal handlers