| From: | Robert Treat <rob(at)xzilla(dot)net> |
|---|---|
| To: | VASUKI M <vasukianand0119(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Optional skipping of unchanged relations during ANALYZE? |
| Date: | 2026-01-20 20:26:52 |
| Message-ID: | CABV9wwNYQ6V4-kKzPbJ0fGtgrq_+0z1kLiWQ8yqqDL-hEmphdQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 20, 2026 at 5:24 AM VASUKI M <vasukianand0119(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-01-20 20:31:11 | Re: Custom oauth validator options |
| Previous Message | Konstantin Knizhnik | 2026-01-20 20:25:26 | Re: Mystery with REVOKE PRIVILEGE |