Re: Why isn't my table auto-analyzed/vacuumed?
Adrian Klaver <adrian.klaver@aklaver.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
To: Dimitrios Apostolou <jimis@gmx.net>, Ron Johnson <ronljohnsonjr@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Date: 2025-10-31T20:52:05Z
Lists: pgsql-general
On 10/31/25 13:03, Dimitrios Apostolou wrote: > On Thursday 2025-10-30 18:00, Ron Johnson wrote: > >> >> > SELECT reltuples FROM pg_class WHERE relname = >> 'test_runs_summarized_per_function' \gx >> -[ RECORD 1 ]----------- >> reltuples | 6.061923e+09 >> >> > SELECT name,setting FROM pg_settings WHERE name ILIKE '%factor%' ; >> name | setting >> ---------------------------------------+--------- >> autovacuum_analyze_scale_factor | 0.1 >> >> >> 0.1 means 10%. >> >> autovacuum_vacuum_insert_scale_factor | 0.2 >> autovacuum_vacuum_scale_factor | 0.2 >> recursive_worktable_factor | 10 >> >> >> n_mod_since_analyze=423101205 >> n_live_tup=6484485348 >> >> n_mod_since_analyze/n_live_tup = 6.5% >> >> How can I get more info from postgres on the autovacuum logic? >> >> >> I would: >> 1) manually VACUUM ANALYZE the table, >> 2) drop the three autovacuum_*_scale_factor values down to 0.03 (i.e. >> 3%), > > Reporting back, after reducing the values, the table has been picked up > for both autovacuum and analyze. Thank you for the immediate feedback! > > Since I had spent some time looking into these values and was "certain" > that they were % while they are apparently *not*, I'm wondering if > max_val=100 is there because of historical reasons, and if it would make > sense to change it to 1. But they are: 0.1/1 is 10% as is 10/100. > > > Dimitris -- Adrian Klaver adrian.klaver@aklaver.com