성능

“테이블이 커서 파티셔닝했다"는 말을 자주 듣는다. 그리고 그 뒤에 “그런데 안 빨라졌다"가 따라오는 경우도 자주 본다. 파티셔닝은 쿼리를 빠르게 하는 기능이 아니다. 조건에 맞는 파티션만 읽게 하는 기능이다. 그 조건이 안 갖춰지면 이득은 없고 비용만 남는다. 파티션 프루닝 주문 테이블을 월별로 나눴다고 하자. CREATE TABLE orders ( id bigint, created_at timestamptz NOT NULL, ... ) PARTITION BY RANGE (created_at); CREATE TABLE orders_2026_08 PARTITION OF orders FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'); CREATE TABLE orders_2026_09 PARTITION OF orders FOR VALUES FROM ('2026-09-01') TO ('2026-10-01'); 이 쿼리는 9월 파티션 하나만 읽는다. ...

시리즈 마지막이다. 앞의 두 편에서 행 수 추정을 맞추는 이야기를 했다. 이번엔 추정이 맞아도 인덱스를 안 쓰는 경우다. 인덱스를 만들었는데 EXPLAIN에 여전히 Seq Scan이 나온다. 이때 먼저 가를 것이 있다. 플래너가 인덱스를 못 쓰는 건지, 안 쓰는 건지. 못 쓰는 경우 조건의 모양이 인덱스와 안 맞으면 플래너는 선택지 자체가 없다. 컬럼에 함수를 씌웠다. WHERE lower(email) = 'a@b.com' -- email 인덱스 못 씀 WHERE date(created_at) = '2026-09-01' -- created_at 인덱스 못 씀 WHERE created_at + interval '1 day' > now() 인덱스는 email의 값으로 정렬돼 있지 lower(email)의 값으로 정렬돼 있지 않다. 표현식 인덱스를 만들거나, 조건을 컬럼이 그대로 남는 형태로 바꾼다. ...

지난 편은 컬럼 하나의 통계가 틀리는 경우였다. 이번 편은 컬럼 하나하나는 정확한데 함께 쓰면 틀리는 경우다. 이쪽이 더 자주, 더 크게 빗나간다. 독립 가정 주소 테이블이 있다. sido(시도)와 sigungu(시군구) 컬럼이 있다. SELECT * FROM addresses WHERE sido = '서울특별시' AND sigungu = '강남구'; 플래너는 이렇게 계산한다. sido = '서울특별시'인 비율: 최빈값 목록에서 찾음. 20%라고 하자. sigungu = '강남구'인 비율: 최빈값 목록에서 찾음. 2%라고 하자. 둘 다 만족하는 비율: 20% × 2% = 0.4% 그런데 강남구는 서울에만 있다. sigungu = '강남구'인 행은 전부 sido = '서울특별시'다. 실제 비율은 2%다. 플래너는 5배 적게 추정했다. ...

EXPLAIN ANALYZE를 보면 두 숫자가 나란히 있다. rows=100과 actual rows=1500000. 플래너는 백 행이 나올 줄 알고 계획을 짰는데 실제로는 백오십만 행이 나왔다. 그 계획은 백 행에 맞는 계획이었을 테니, 결과는 느린 쿼리다. 플래너가 왜 백 행이라고 생각했는지를 따라가면 통계에 닿는다. 이 시리즈는 그 통계 이야기다. 통계는 표본이다 플래너는 실행 전에 테이블을 읽지 않는다. ANALYZE가 미리 만들어둔 요약을 본다. ANALYZE는 테이블 전체를 읽지 않는다. 표본을 뽑는다. 표본 크기는 default_statistics_target × 300이고, 기본값이 100이라 3만 행이다. 테이블이 천 행이든 십억 행이든 3만 행이다. ...

앞선 세 편은 이미 생긴 죽은 튜플을 어떻게 치울 것인가에 대한 이야기였다. 이번 편은 반대쪽이다. 애초에 덜 만드는 방법. UPDATE가 인덱스까지 건드리는 문제 PostgreSQL에서 UPDATE는 새 버전을 쓰는 일이라고 1편에서 정리했다. 그런데 여기 딸려오는 비용이 하나 더 있다. 새 버전이 생기면 그 위치를 가리키도록 인덱스도 갱신해야 한다. 인덱스가 다섯 개인 테이블에서 한 행을 UPDATE하면, 힙에 새 버전 하나가 생기고 인덱스 다섯 곳에 엔트리가 추가된다. 그래서 갱신이 잦은 테이블은 힙보다 인덱스가 먼저 부푸는 경우가 많다. 그리고 인덱스 팽창은 조회 성능에 직접 영향을 준다. ...