Можно ли отключить avtovacuum для таблицы

Добрый день.
Хотелось бы услышать ваше мнение.
Есть отдельная база с таблицами. Таблицы партицированы.
Происходить только INSERT/SELECT. Т.е UPDATE/DELETE некогда в принципе.
Хочу отключить автовакум для таких таблиц опираясь на отсутствие необходимости освобождения места и чисток.
Но смущает возможная дальнейшая работа планировщика. С чем могу столкнутся ? Все запросы на выборку обернуты в хранимки, соответственно планы кешируються.
Спасибо!

Electric200,


ALTER TABLE ... SET (...);

Electric200

Добрый день. Хотелось бы услышать ваше мнение. Есть отдельная база с таблицами. Таблицы партицированы. Происходить только INSERT/SELECT. Т.е UPDATE/DELETE некогда в принципе. Хочу отключить автовакум для таких таблиц опираясь на отсутствие необходимости освобождения места и чисток. Но смущает возможная дальнейшая работа планировщика. С чем могу столкнутся ? Все запросы на выборку обернуты в хранимки, соответственно планы кешируються. Спасибо!

autovacuum это не только автоматический vacuum но и автоматический analyze (обновление статистики)
если удалений и update нет то autovacuum vacuum на них и так не будет работать и отключать его смысла ровно 0

--Maxim Boguk
www.postgresql-consulting.ru

vyegorov
Electric200, ALTER TABLE ... SET (...);

Спасибо.. Я знаю как отключить, я не знаю есть ли смыл.
--Maxim Boguk
Да, вы правы.
Дело в том, что я частенько замечаю

autovacuum: VACUUM ANALYZE public."TABLENAME"

в активных процессах. И на этот период система слегка проседает по IO.
Вот и задался вопросом. А нужно ли, и если да - то зачем?

Electric200
vyegorov Electric200, ALTER TABLE ... SET (...); Спасибо.. Я знаю как отключить, я не знаю есть ли смыл. --Maxim Boguk Да, вы правы. Дело в том, что я частенько замечаю autovacuum: VACUUM ANALYZE public."TABLENAME" в активных процессах. И на этот период система слегка проседает по IO. Вот и задался вопросом. А нужно ли, и если да - то зачем?

нужно
если на таблице не было delete/update - то AUTOVACUUM VACUUM и не будет (ну кроме как antiwraparound autovacuum который к счастью отключить невозможно почти).

--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk, я вас тогда еще помучаю.
Почему тогда ANALYZE выполняется для таблиц, у которых продолжительное время не было изменений? Под "продолжительным" имею ввиду месяцы. Может ли это быть как то связано с партицированием? Когда автовакуум определяет изменения в таблице "мастер" и подразумевает наличие изменений в дочерних партициях, хотя там изменений нет. Вроде как "партицирование" в PG реализовано на уровне тригеров, и для автовакуума это должен быть однотипный набор таблиц. Или связь все таки есть?

Конечно сам ANALYZE проходит шустро, но при наличие базы в теребайты с наполнением миллионами записей в сутки, считаю ANALYZE для таблиц где месяцами не было изменений дело избыточным.
Спасибо!

Electric200,

покажите вывод

select * from pg_stat_user_tables where relname = 'tablename';

для таблиц, на которых autoanalyze работает, но никаких изменений нет (включаяя insert'ы).

Alexius,

autovacuum: VACUUM public.2381_ODP_2014-12-01 (to prevent wraparound)

Результат

select * from pg_stat_user_tables where relname = '2381_ODP_2014-12-01';

relid  | schemaname |       relname       | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze |       last_autoanalyze        | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count 
--------+------------+---------------------+----------+--------------+----------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------+-----------------+--------------+-------------------------------+--------------+------------------+---------------+-------------------
 492598 | public     | 2381_ODP_2014-12-01 |        3 |            0 |        0 |             0 |  11461905 |         0 |         0 |             0 |   11439108 |      17851 |             |                 |              | 2015-03-16 10:45:16.249871+00 |            0 |            

Electric200,

это to prevent wraparound autovacuum. вот здесь подробнее про него можно прочитать.
в том числе там указаны рекомендации по увеличению autovacuum_freeze_max_age и ручному вызову vacuum freeze в периоды низкой нагрузки в качестве решения проблемы.

Electric200

Alexius, autovacuum: VACUUM public.2381_ODP_2014-12-01 (to prevent wraparound) Результат select * from pg_stat_user_tables where relname = '2381_ODP_2014-12-01'; relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze | vacuum_count | autovacuum_count | analyze_count | autoanalyze_count --------+------------+---------------------+----------+--------------+----------+---------------+-----------+-----------+-----------+---------------+------------+------------+-------------+-----------------+--------------+-------------------------------+--------------+------------------+---------------+------------------- 492598 | public | 2381_ODP_2014-12-01 | 3 | 0 | 0 | 0 | 11461905 | 0 | 0 | 0 | 11439108 | 17851 | | | | 2015-03-16 10:45:16.249871+00 | 0 |

от (to prevent wraparound) autovacuum вы никуда не уйдете даже если отключите autovacuum на таблице целиком. Это обязательная процедура которую можно конечно заменить ручным vacuum freeze но обьем дисковой нагрузки от этого меньше не станет.
Если у вас от autovacuum проседают диски - вам надо или диски быстрее поставить или подобрать autovacuum_vacuum_cost_delay такой чтобы диски справлялись (но без фанатизма autovacuum работающий на таблице сутки это печально).

--Maxim Boguk
www.postgresql-consulting.ru