Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
От | Rihad |
---|---|
Тема | Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? |
Дата | |
Msg-id | 329abf6c-2165-f410-717f-c20b3dd0a3d7@gmail.com обсуждение исходный текст |
Ответ на | Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
|
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: