Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
В списке pgsql-general по дате отправления:
| От | Rihad |
|---|---|
| Тема | Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? |
| Дата | |
| Msg-id | 3fafd9d5-ba37-8abf-ba46-ca51b6f706c9@gmail.com обсуждение |
| Ответ на | Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Список | pgsql-general |
On 8/21/23 09:31, Rihad wrote: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:
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.
My only remaining suggestion is to closely monitor the Postgres log and see if provides a clue.
I'm awfully sorry, I read the autovacuum manual carefully, it isn't n_live_tup, but reltuples that is taken into account during the calculation.
vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples
where the vacuum base threshold is autovacuum_vacuum_threshold, the vacuum scale factor is autovacuum_vacuum_scale_factor, and the number of tuples is pg_class.reltuples.
Your first suggestion was to RTFM.
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера