kind: capsule status: active visibility: private license: public-domain summary: Postgres autovacuum 기본 scale_factor 0.2는 대형 테이블에서 과도하게 지연된다. 테이블 크기별 per-table override 권장. tags: - postgres - ops - performance - capsule related: - personal_vault/knowledge/dev/postgres-advanced.md

Postgres Autovacuum Tuning Capsule

Core claim#

Postgres autovacuum은 n_dead_tup / n_live_tup > autovacuum_vacuum_scale_factor + autovacuum_vacuum_threshold / reltuples 조건에서 트리거된다. 기본값 scale_factor=0.2, threshold=50은 작은 테이블에는 합리적이지만 1천만 행 이상에서는 200만 dead tuple이 쌓일 때까지 지연되어 bloat + 쿼리 지연을 유발한다.

When to apply#

테이블 크기 1M rows 초과
쓰기 부하가 높아 pg_stat_user_tables.n_dead_tup 증가 속도가 빠른 경우
autovacuum 로그에서 skipping "..." --- only superuser can vacuum it 반복 시

Recipe (per-table override)#

ALTER TABLE big_events SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_scale_factor = 0.01
);

0.02는 "2% dead tuple 쌓이면 vacuum" 의미 — 1천만 행 테이블에서는 20만 dead tuple 기준
HOT update 비율이 높으면 fillfactor=90 같이 조정

Monitoring#

pg_stat_user_tables.last_autovacuum, autovacuum_count
bloat 추적: pgstattuple extension의 pgstattuple_approx()

Caveats#

scale_factor를 너무 낮추면 autovacuum worker 점유율이 올라가 autovacuum_max_workers(기본 3) 부족 가능
TOAST 테이블은 별도 autovacuum 대상 — pg_class.reltoastrelid로 확인
대형 vacuum은 I/O throttling(autovacuum_vacuum_cost_limit) 고려

Source#

PostgreSQL 공식 문서 "Routine Vacuuming": https://www.postgresql.org/docs/current/routine-vacuuming.html (PostgreSQL License, public-domain 등가)
"Automatic Vacuuming" 섹션: https://www.postgresql.org/docs/current/runtime-config-autovacuum.html
조회일: 2026-04-19

Sagwan Revalidation 2026-04-19T00:05:48Z#

verdict: ok
note: 공식 문서 링크·SQL 문법·수치 모두 PG 17 기준으로도 유효하며 현행 best practice와 일치한다.