PostgreSQL에서 DELETE를 많이 했는데 파일 크기가 줄지 않고 조회도 느려집니다. VACUUM은 무엇을 정리하나요?

MVCC에서 삭제·갱신한 이전 튜플은 아직 필요한 트랜잭션이 있을 수 있어 즉시 물리 제거하지 않습니다. VACUUM은 더 이상 보이지 않는 튜플을 정리하고 공간을 재사용 가능하게 하며 가시성·동결 관리에도 관여합니다.

동작 원리와 전제

일반 VACUUM이 항상 파일을 OS에 크게 반환하는 것은 아닙니다. 내부 공간 재사용과 파일 축소는 구분하고, VACUUM FULL 같은 재작성은 별도 잠금·공간 비용이 있습니다. 긴 트랜잭션이나 복제 슬롯 등은 정리 가능한 경계를 지연시킬 수 있습니다.

선택과 실패 처리

테이블별 변경률과 autovacuum 임계·실행 지연, dead tuple 추정치와 오래된 트랜잭션을 확인합니다. 단순히 주기를 공격적으로 줄이면 I/O 경쟁이 커질 수 있어 테이블 크기와 부하에 맞춥니다. 트랜잭션 ID wraparound 예방과 일반적인 bloat 정리는 관련 있지만 같은 운영 증상은 아닙니다.

구체적인 사례와 검증

오래된 보고서 transaction이 스냅샷을 유지하면 삭제한 행이 그 보고서에는 여전히 필요할 수 있습니다. vacuum을 실행해도 그 버전을 당장 제거하지 못하는 이유입니다. 보고서 범위를 줄이거나 별도 추출·분석 경로를 사용하되 필요한 일관성을 잃지 않게 합니다. 디스크를 줄여야 한다면 재작성 작업의 추가 공간과 잠금·복제 부하를 계획합니다. 정리 후에도 RSS가 즉시 줄지 않을 수 있어 DB 파일·buffer cache·OS 메모리를 구분합니다. 지표의 dead tuple 수는 추정일 수 있으므로 단일 숫자만 보고 파괴적인 정리를 하지 않고 실제 계획과 장기 추세를 대조하겠습니다.

삭제 전후 파일·재사용 공간·쿼리 읽기·vacuum 진행을 비교하고 긴 스냅샷을 유지하는 경우를 재현합니다. vacuum을 끄는 것으로 지연을 숨기지 않습니다. 논리적으로 행이 사라진 시점, 공간이 재사용되는 시점, 파일이 줄어드는 시점을 따로 설명하겠습니다.