6장. 쿼리 플래너와 EXPLAIN

"인덱스가 있는데 왜 Seq Scan을?" — 그 답은 플래너의 머릿속에 있습니다. 비용 기반 옵티마이저가 계획을 고르는 원리와, EXPLAIN으로 그 속마음을 읽는 법을 배웁니다.

6.1 파이프라인 — SQL 한 줄이 계획이 되기까지

PostgreSQL은 비용 기반 옵티마이저(cost-based optimizer)입니다. 가능한 실행 계획들을 열거하고 예상 비용을 계산해 가장 싸 보이는 하나를 고릅니다. "싸 보인다"는 판단이 통계와 파라미터에 의존한다는 점이 이 장 전체의 복선입니다.

6.2 Cost 모델 — 숫자의 단위는 "순차 페이지 1장"

EXPLAIN에 나오는 cost는 초(second)가 아니라 단위 없는 상대값입니다. 기준은 "페이지 하나를 순차로 읽는 비용 = 1.0".

# postgresql.conf — SSD/NVMe 권장 출발점
random_page_cost = 1.1
effective_cache_size = '12GB'   # RAM의 50~75% 수준

6.3 통계 — 플래너의 눈, ANALYZE로 닦아준다

선택도 추정의 근거는 ANALYZE가 수집해 pg_statistic(뷰: pg_stats)에 저장한 통계입니다: 고유값 수(n_distinct), 최빈값(most_common_vals), 히스토그램, 물리 정렬 상관(correlation)…. 이 통계가 낡으면 무슨 일이 벌어지는지 봅시다.

-- 통계 들여다보기
SELECT attname, n_distinct, most_common_vals, correlation
FROM pg_stats WHERE tablename = 'orders' AND attname = 'user_id';

-- 분포가 복잡한 컬럼은 표본을 늘린다 (기본 100)
ALTER TABLE orders ALTER COLUMN user_id SET STATISTICS 1000;
ANALYZE orders;

-- 컬럼 간 상관(예: city ↔ zip_code)은 확장 통계로 (10+)
CREATE STATISTICS s_orders_region (ndistinct, dependencies, mcv)
  ON city, zip_code FROM orders;

6.4 조인 3종 세트 — Nested Loop · Hash · Merge

두 테이블을 묶는 방법은 세 가지뿐입니다. 각자의 동작을 한 화면에서 비교해 봅시다.

6.5 EXPLAIN 읽기 — 다섯 가지만 먼저 본다

EXPLAIN (ANALYZE, BUFFERS)
SELECT u.name, SUM(o.amount)
FROM users u JOIN orders o ON o.user_id = u.id
WHERE u.signup_date >= '2026-01-01'
GROUP BY u.name ORDER BY 2 DESC LIMIT 20;

Limit  (cost=12345.67..12345.72 rows=20) (actual time=234.5..234.6 rows=20 loops=1)
  Buffers: shared hit=1234 read=56
  ->  Sort  (Sort Method: top-N heapsort  Memory: 31kB)
        ->  HashAggregate
              ->  Hash Join  (Hash Cond: o.user_id = u.id)
                    ->  Seq Scan on orders o
                    ->  Hash  (Buckets: 2048  Batches: 1  Memory Usage: 85kB)
                          ->  Seq Scan on users u
                                Filter: signup_date >= '2026-01-01'
                                Rows Removed by Filter: 19200
Planning Time: 0.42 ms
Execution Time: 235.1 ms

6.6 운영에서는 auto_explain — 느린 쿼리만 자동 채집

# postgresql.conf
shared_preload_libraries = 'auto_explain'   # 재시작 필요
auto_explain.log_min_duration = '500ms'     # 이보다 느린 쿼리만 로그
auto_explain.log_analyze = on
auto_explain.log_buffers = on
auto_explain.sample_rate = 1.0              # 고TPS면 0.01~0.1로

추천 조합: pg_stat_statements로 "빈도 × 평균 시간"이 큰 문제 쿼리 후보를 찾고 → auto_explain 로그에서 실제 계획을 확인하고 → 재현 환경에서 EXPLAIN (ANALYZE, BUFFERS)로 튜닝합니다.

✍️ 이해도 체크