Re: Optional skipping of unchanged relations during ANALYZE?
| От | Ilia Evdokimov |
|---|---|
| Тема | Re: Optional skipping of unchanged relations during ANALYZE? |
| Дата | |
| Msg-id | cc3fde9a-6989-4e9f-8f74-92891c864757@tantorlabs.com обсуждение исходный текст |
| Ответ на | Optional skipping of unchanged relations during ANALYZE? (VASUKI M <vasukianand0119@gmail.com>) |
| Список | pgsql-hackers |
Hi everyone, On 20.01.2026 13:24, VASUKI M wrote: > I’m planning to work on a small improvement around ANALYZE behavior and > wanted to ask the community for guidance before proceeding. Thanks for working on this — it indeed looks like it could reduce the time spent executing ANALYZE. > > 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). We should consider n_mod_since_analyze as well. > > Before moving forward, I’d like to understand: > > --whether this aligns with PostgreSQL’s statistics and planner design, > > --if there are reasons ANALYZE should always re-run even for unchanged > relations, > > --and whether such behavior would be acceptable if it were strictly > opt-in. > > Any feedback, concerns, or pointers would be very helpful. One concern that comes to mind is changes in statistics targets. For example, statistics may have been collected with default_statistics_target = 100, and later either default_statistics_target or a per-column statistics target is increased (e.g., to 200). As far as I know, we currently do not track which statistics target was used when the existing statistics were collected. If someone knows a reliable way to determine this, please correct me. If we cannot determine that, we would need to decide whether such relations should still be skipped -- Best regards, Ilia Evdokimov, Tantor Labs LLC, https://tantorlabs.com/
В списке pgsql-hackers по дате отправления: