Добрый день! Очень не силен в vacuum и просьба подсказать

вот такой момент:

имеется табличка весом 168 MB
есть настройки autovacuum:

autovacuum = on
log_autovacuum_min_duration = -1
autovacuum_max_workers = 3
autovacuum_naptime = 1min
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.1
autovacuum_freeze_max_age = 200000000
autovacuum_multixact_freeze_max_age = 400000000
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = -1

при этом

select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables
where relname = 'table'

показывает что процесс автовакуума проходит/проходил

но при этом: live 623142 dead 18074188

Где можно доходчиво почитать, как настроить правильно автовакуум? и возможно ли вообще его средствами избавиться от мертвых кортежей?

https://postgrespro.ru/docs/postgresql/13/runtime-config-autovacuum

спасибо! и не могли бы уточнить, пожалуйста, avtovacuum все же чистит мертвые кортежы или же шринкует табличку? те я могу избежать при его использовании фулл вакуум который ее пересоздает (дефрагментирует)

vacuum full можно и иногда даже нужно избегать. vacuum работает как-то сложно и в двух словах это не описать :)

vacuum full боюсь мне совсем не подойдет, тк залочет табличку а она у меня не одна проблемная … при этом, хотелось бы конечно понять изначально поможет ли мне автовакуум, те стоит ли крутить его настройки или же сразу переключиться к неким альтернативным методам например https://reorg.github.io/pg_repack/

Если данные неудачно разлеглись, то autovacuum не поможет и можно сразу переходить к альтернативным методам

> avtovacuum все же чистит мертвые кортежы Да. > или же шринкует табличку? Нет (может "отрезать" пустой "хвост", максимум). > те я могу избежать при его использовании фулл вакуум который ее пересоздает (дефрагментирует) Если Вам autovacuum не помог от них по какой-то причине, то и VACUUM FULL не поможет, если эта причина всё ещё существует.

в общем, проанализировав метрики мониторинга пришли к выыоду что лочит walreceiver кильнул процесс walreceiver и все заработало

блин вот че все с этим вакуумом. проще базу выгрузил - загрузил. автоматом. и действий меньше и реиндексить не надо. и вакуум свои дела сделает как надо.

> блин вот че все с этим вакуумом. Потому что autovacuum — это штатное средство maintenance в PostgreSQL. > проще базу выгрузил - загрузил. Это, фактически, VACUUM FULL "автоматом". > и реиндексить не надо Так и обычно не надо. > и вакуум свои дела сделает как надо И обычный VACUUM он, вполне возможно, не сделает (как и ANALYZE), или сделает позже. И, по совокупности вышеописанного, может стать намного хуже, чем если бы всё это не делалось вообще.

ну... я админил 15 магазинов с ПГ. и вот эта мышиная возня с отдельными вакуумами и переиндексациями.... а когда выгрузил загрузил - сразу убиваешь трех зайцев- и базу обслужил и копию базы сделал

а зачем? автоваккума не хватало?

> и вот эта мышиная возня с отдельными вакуумами и переиндексациями.... Это Вы про ту возню, которая почти всегда бесполезна и даже вредна? В общем, для этого есть autovacuum, и тащить в PostgreSQL привычные для для каких-то других СУБД "пляски с бубном" не нужно, я считаю. ;) > а когда выгрузил загрузил - сразу убиваешь трех зайцев- и базу обслужил и копию базы сделал Ага, "обслужил", а как же. Это вполне может быть вариант: оказал медвежью услугу, но "железо" (к счастью) вытянуло. ;( В общем, подобным в PostgreSQL без конкретных причин заниматься не нужно, как и советовать такое другим, вот в чём мой посыл.

не буду спорить но я делал изначально как правильно- все по отдельности. но на практике все свелось к тому как написал

Ну а я буду. Это не правильно — это типичные сисадминские "ритуальные пляски" / имитация бурной деятельности, и больше ничего. :(

какие пляски? все делается шедулером в автоматическом режиме.

Такие. Вот то, что им делается (я повторю ещё раз) — как минимум не нужно, и в худшем случае вредно.