Feedback-ID: i76984098:Fastmail
Message-ID: <c84754cf-f69c-4d5c-a78a-38f3e71cc7fd@aklaver.com>
Date: Fri, 31 Oct 2025 13:52:05 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Why isn't my table auto-analyzed/vacuumed?
To: Dimitrios Apostolou <jimis@gmx.net>, Ron Johnson <ronljohnsonjr@gmail.com>
Cc: pgsql-general@lists.postgresql.org
References: <26qs98r6-0q81-non7-3n17-0r14o9851pp9@tzk.arg>
 <CANzqJaDHcDE5j4bo+D7bH7A_GqtimbThRs5h+fnT+m829ZSsPQ@mail.gmail.com>
 <07sp7s76-r633-spqr-so3o-5oqs44r80np6@tzk.arg>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <07sp7s76-r633-spqr-so3o-5oqs44r80np6@tzk.arg>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/c84754cf-f69c-4d5c-a78a-38f3e71cc7fd%40aklaver.com>
Precedence: bulk

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