Re: autoanalyze did not run - Mailing list pgsql-admin

From Laurenz Albe
Subject Re: autoanalyze did not run
Date
Msg-id 70a8b93495f2e84a167bc0afab13c637be04fdf7.camel@cybertec.at
Whole thread Raw
In response to autoanalyze did not run  (Олег Самойлов <splarv@ya.ru>)
Responses Re: autoanalyze did not run
List pgsql-admin
On Tue, 2026-01-27 at 14:39 +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.
>
> 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.

Ok.  As Sherlock Holmes said, if you have excluded everything impossible, what remains
must be what happened, however unlikely it seems.

I conclude that your database cluster must have crashed.  Crash recovery will wipe out all
statistics and reset "pg_stat_database.stats_reset" to NULL.

Yours,
Laurenz Albe

pgsql-admin by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: autoanalyze did not run
Next
From: Олег Самойлов
Date:
Subject: Re: autoanalyze did not run