| From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
|---|---|
| To: | VASUKI M <vasukianand0119(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Christoph Berg <myon(at)debian(dot)org> |
| Subject: | Re: Optional skipping of unchanged relations during ANALYZE? |
| Date: | 2026-01-23 10:44:18 |
| Message-ID: | 65da80c0-52fb-454e-b29e-b1d5a254ec38@tantorlabs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23.01.2026 09:33, VASUKI M wrote:
> Relation to vacuumdb --missing-stats-only
> I agree this is related but slightly different in intent.
> --missing-stats-only answers “does this table have any statistics at
> all?”, while SMART ANALYZE answers “has this table changed since the
> last statistics collection?”. Both seem useful, but they target
> different use cases. I see SMART ANALYZE primarily as a performance
> optimization for repeated manual ANALYZE runs on mostly-static schemas.
LGTM. Thanks to Sami for pointing this out.
It seems reasonable to start by introducing an option for plain ANALYZE
(without specifying tables or columns) that follows the same idea as
vacuumdb --missing-stats-only. While this flag was originally introduced
primarily to support pg_upgrade workflows, exposing similar
functionality at the ANALYZE level also seems useful on its own. That
would give us a clear and well-defined first step. At the SQL level, a
name such as ANALYZE (MISSING_STATS_ONLY) would be a good fit and remain
consistent with the vacuumdb option.
Thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC,
https://tantorlabs.com/
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Michael Banck | 2026-01-23 10:43:22 | Re: Time to drop RADIUS support? |