Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
Date
Msg-id 9fed2b70-cc36-1239-d5b6-7a81afeafb82@aklaver.com
Whole thread Raw
In response to Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?  (Rihad <grihad@gmail.com>)
Responses Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
List pgsql-general
On 8/21/23 09:09, Rihad wrote:
> On 8/21/23 20:00, Adrian Klaver wrote:


> Thanks for the detailed reply, no tables have custom settings.
> 
> I need to make it clear once again that all autovac/analyze work as 
> expected when n_live_tup matches reality, i.e. when analyze has been run 
> on them since last reset.
> 
> A way to fix this is to simply analyze the whole database. Before doing 
> that, while n_live_tup starts from basically 0 and grows based on DB 
> activity, these usual calculations of 10-20% table size for 
> vacuum/analyze don't work. They don't trigger autovac for most tables, 
> or do it much much later.
> 

You still have not said or shown whether the other autovacuum settings 
are the default values or not. Assuming they are, then the only other 
explanation I can come up with is that there is a process or processes 
that are creating long running open transactions that prevent autovacuum 
from running on the affected tables.

-- 
Adrian Klaver
adrian.klaver@aklaver.com




pgsql-general by date:

Previous
From: Rihad
Date:
Subject: Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
Next
From: Adrian Klaver
Date:
Subject: Re: Will PostgreSQL 16 supports native transparent data encryption ?