Re: Optional skipping of unchanged relations during ANALYZE? - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Optional skipping of unchanged relations during ANALYZE?
Date
Msg-id CABV9wwNYQ6V4-kKzPbJ0fGtgrq_+0z1kLiWQ8yqqDL-hEmphdQ@mail.gmail.com
Whole thread Raw
In response to Optional skipping of unchanged relations during ANALYZE?  (VASUKI M <vasukianand0119@gmail.com>)
Responses Re: Optional skipping of unchanged relations during ANALYZE?
List pgsql-hackers
On Tue, Jan 20, 2026 at 5:24 AM VASUKI M <vasukianand0119@gmail.com> wrote:
>
> Hi Hackers,
>
> I’m planning to work on a small improvement around ANALYZE behavior and
> wanted to ask the community for guidance before proceeding.
>
> Currently, when ANALYZE is run over many relations, it analyzes all
> eligible tables even if some of them have not changed since their last
> ANALYZE. In environments with many mostly-static tables, this can lead
> to repeated work with little benefit.
>
> I’m considering working on an optional mode where ANALYZE would skip
> relations that have not been modified since their last analyze, based
> on existing pg_stat counters (for example, mod_since_analyze = 0).
>
> Before moving forward, I’d like to understand:
>
> --whether this aligns with PostgreSQL’s statistics and planner design,
>

I think it makes sense generally, and one could maybe argue that it
should be the default behavior; have you done any research into why it
doesn't behave that way already?

> --if there are reasons ANALYZE should always re-run even for unchanged
> relations,
>

Given ANALYZE does a random sample, on rare occasions it can be
valuable to re-run analyze to get a better sample than whatever
statistics were obtained previously, even in the case the data itself
does not change. I suppose more likely scenarios would be modification
of default_statistics_target either at server or table level
(adding/removing), but the point is there are scenarios where you
might want to rerun it, so we do need to support both behaviors.

> --and whether such behavior would be acceptable if it were strictly
> opt-in.
>

Given my above, it does have to be something that can be turned on or
off, so even if we don't know which is the best default behavior, it
makes sense to start by doing it in a way that is optional.


Robert Treat
https://xzilla.net



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Mystery with REVOKE PRIVILEGE
Next
From: Zsolt Parragi
Date:
Subject: Re: Custom oauth validator options