post(blog): PostgreSQL 인덱스 설계 — DESC 인덱스와 커버링 인덱스 (#60)

[Malloc72P]

Closes #60

요약

노션 노트 PG 성능 최적화를 포스트로 옮기려다 노트의 핵심 주장이 틀렸다는 걸 발견해서, 실측으로 확인한 뒤 노트와 포스트를 함께 바로잡았습니다.

노트에 적혀 있던 주장:

PostgreSQL 인덱스는 기본적으로 ASC로 생성되며, DESC 쿼리를 위해 역순으로 스캔합니다. 명시적으로 DESC 인덱스를 생성하면 역순 스캔 대신 정방향 스캔이 되어 성능이 더 좋습니다.

docker postgres:18에 500만 행 로그 테이블을 만들어 재보니 단일 컬럼 정렬에서는 방향이 무의미했습니다. 대신 방향이 실제로 필요한 조건이 따로 있었습니다.

측정 결과

시나리오	비교	결과	반복
ORDER BY ts DESC LIMIT 1000	인덱스 없음	412.52ms	5
	(ts) — Index Scan Backward	0.13ms	20
	(ts DESC) — Index Scan	0.12ms	20
ORDER BY service ASC, ts DESC	(service, ts) — Incremental Sort	377.88ms	10
	(service ASC, ts DESC) — Index Scan	0.23ms	10
20만 행 반환	(ts DESC) — Index Scan	32.20ms	10
	INCLUDE 추가 — Index Only Scan	21.22ms	10
count(*) (약 282만 행)	(ts DESC)	71.53ms	10
	INCLUDE 추가	80.52ms	10

• 효과의 대부분은 인덱스 유무에서 나옵니다(약 3,000배). 방향은 여기에 기여하지 않습니다.
• 방향이 의미를 갖는 건 정렬 방향이 섞이는 복합 정렬입니다(약 1,600배). NULLS 위치를 지정할 때도 마찬가지입니다.
• 커버링 인덱스는 스캔 폭이 넓을 때만 이득이고, count(*)와 쓰기는 오히려 느려집니다.

포스트 구성

backend 시리즈, 562줄. 이슈에는 예상 시리즈가 fullstack으로 적혀 있었지만 내용이 DB 쪽에 치우쳐 backend로 넣었습니다.

재현용 스크립트(docker 기동 + 더미 데이터 적재 + 측정)를 본문에 그대로 포함했습니다.

검증

• pnpm --filter blog build 통과 (132 페이지)
• 검색 인덱스 description 정상 (35개 포스트 중 빈 값 0개)
• dev 서버 200, H2 9개 · H3 5개 · 표 15행 · 코드 블록 28개 렌더 확인
• 초안 검증에서 나온 오류 8건(계획 출력 불일치, 반복 횟수 오기, 워커 수 오기, pg_total_relation_size 해석 등) 수정 완료

노션 노트

같은 내용으로 원본 노트도 교정했습니다 — 교정 배너 추가, 1·2번 본문 교체, 측정 근거 섹션 추가, 코드 블록의 붙여넣기 흔적 정리.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
blog	Ignored		Aug 11, 2026 4:09am