시리즈 마지막이다. 앞의 두 편에서 행 수 추정을 맞추는 이야기를 했다. 이번엔 추정이 맞아도 인덱스를 안 쓰는 경우다. 인덱스를 만들었는데 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만 행이다. ...