On Fri, Oct 31, 2025 at 4:52 PM Adrian Klaver <[email protected]> wrote:
> 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. > And 0.1/100 = 0.1%. Dimitrios is right: it's misleading to have a default of 0.1 that means 10%, but also have the max value be 100 because 10 is 10% of 100. https://www.postgresql.org/docs/17/runtime-config-autovacuum.html#GUC-AUTOVACUUM-ANALYZE-SCALE-FACTOR certainly doesn't mention that you can use either reals (0,1] or integers (0,100]. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
