Re: autoanalyze did not run - Mailing list pgsql-admin
| From | Kristjan Mustkivi |
|---|---|
| Subject | Re: autoanalyze did not run |
| Date | |
| Msg-id | CAOQPKavjTPzfrfvyR2DM4ALo7ea7vrbc3rh2h-qB_2S0C7wijw@mail.gmail.com Whole thread Raw |
| In response to | autoanalyze did not run (Олег Самойлов <splarv@ya.ru>) |
| Responses |
Re: autoanalyze did not run
|
| List | pgsql-admin |
On Tue, Jan 27, 2026 at 1:40 PM Олег Самойлов <splarv@ya.ru> wrote: > ---------------- > Кому: Олег Самойлов (splarv@ya.ru), Pgsql-admin (pgsql-admin@lists.postgresql.org); > Тема: autoanalyze did not run; > 26.01.2026, 19:03, "Laurenz Albe" <laurenz.albe@cybertec.at>: > > On Mon, 2026-01-26 at 17:35 +0300, Олег Самойлов wrote: > > > > I try to investigate why autoanalyze did not run in time of our initial > > > loading data. Yes, I know, running analyze manually is highly > > > recommended in such case. But is must run automatically too. > > > > > > PostgreSQL 17.7 (Debian 17.7-3.pgdg13+1) on x86_64-pc-linux-gnu, > > > compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit (from PGDG) > > > > Are you sure that you committed the transaction? > > I am very sure, thats why there are 13844347 rows in that table. By single copy. > > > > Is "track_activities" set to "on"? > > I checked, yep. > > > Then the only explanation is that all autovacuum workers are active, and this > table is starved. See how many autovacuum workers are visible in pg_stat_activity > and compare that to autovacuum_max_workers. > > Yours, > Laurenz Albe > > Now 0. But they worked. The reason is other. Look, first of all, there was not a statistic reset. > SELECT stats_reset is null FROM pg_stat_database WHERE datname = current_database(); > ?column?\c > ---------- > t > (1 row) > select analyze_count,autoanalyze_count,reltuples, n_live_tup, n_tup_ins, n_tup_upd, n_mod_since_analyze from pg_stat_user_tablesas s join pg_class as c on (s.relid=c.oid) where relkind='r' and reltuples>0 limit 10; > analyze_count | autoanalyze_count | reltuples | n_live_tup | n_tup_ins | n_tup_upd | n_mod_since_analyze > ---------------+-------------------+---------------+------------+-----------+-----------+--------------------- > 0 | 0 | 8 | 0 | 0 | 0 | 0 > 0 | 0 | 76596 | 0 | 0 | 0 | 0 > 0 | 0 | 140997 | 0 | 0 | 0 | 0 > 0 | 0 | 2.088436e+07 | 0 | 0 | 0 | 0 > 0 | 0 | 1.2661012e+07 | 0 | 0 | 0 | 0 > 0 | 0 | 2.288401e+07 | 0 | 0 | 0 | 0 > 0 | 0 | 99926 | 0 | 0 | 0 | 0 > 0 | 0 | 1.5620866e+07 | 0 | 0 | 0 | 0 > 0 | 0 | 17511 | 0 | 0 | 0 | 0 > 0 | 0 | 400926 | 0 | 0 | 0 | 0 > The reason is the n_mod_since_analyze is 0. Thats why autoanalyze didn't started. Hello, I do apologize if I mix something up now, but I would expect COPY to have an effect on "n_ins_since_vacuum" but not "n_mod_since_analyze". COPY inserts rows, it does not update them. With best regards, -- Kristjan Mustkivi Email: kristjan.mustkivi@gmail.com
pgsql-admin by date: