Search Postgresql Archives

Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/21/23 20:17, Adrian Klaver wrote:
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.


Sorry, they are all as per default, commented out in the config.

There are no long running queries, otherwise they wouldn't be vacuumed/analyzed in due time after running first manual analyze, which updates n_live_tup to match reltuples.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux