Re: Why isn't my table auto-analyzed/vacuumed? - Mailing list pgsql-general

From Dimitrios Apostolou
Subject Re: Why isn't my table auto-analyzed/vacuumed?
Date
Msg-id 07sp7s76-r633-spqr-so3o-5oqs44r80np6@tzk.arg
Whole thread Raw
In response to Re: Why isn't my table auto-analyzed/vacuumed?  (Ron Johnson <ronljohnsonjr@gmail.com>)
Responses Re: Why isn't my table auto-analyzed/vacuumed?
List pgsql-general
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.


Dimitris

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Enquiry about TDE with PgSQL
Next
From: Kai Wagner
Date:
Subject: Re: Enquiry about TDE with PgSQL