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
