public inbox for [email protected]
help / color / mirror / Atom feedRe: Why isn't my table auto-analyzed/vacuumed?
2+ messages / 2 participants
[nested] [flat]
* Re: Why isn't my table auto-analyzed/vacuumed?
@ 2025-10-31 20:03 Dimitrios Apostolou <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Dimitrios Apostolou @ 2025-10-31 20:03 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Why isn't my table auto-analyzed/vacuumed?
@ 2025-10-31 20:52 Adrian Klaver <[email protected]>
parent: Dimitrios Apostolou <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Adrian Klaver @ 2025-10-31 20:52 UTC (permalink / raw)
To: Dimitrios Apostolou <[email protected]>; Ron Johnson <[email protected]>; +Cc: [email protected]
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
[email protected]
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-10-31 20:52 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-31 20:03 Re: Why isn't my table auto-analyzed/vacuumed? Dimitrios Apostolou <[email protected]>
2025-10-31 20:52 ` Adrian Klaver <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox