クイズ: 計画と地平線

계획에 rows=1 인데 actual rows=60000 이 찍혔다. 가장 먼저 고칠 것은?

• 작업 메모리를 늘려 정렬이 디스크로 넘어가지 않게 한다
• 그 조건 컬럼의 통계를 다시 잡는다
• 조건 컬럼에 인덱스를 만든다
• 조인 순서를 힌트로 고정한다

병렬 계획의 한 노드에 rows=100000 loops=2 가 찍혀 있다. 이 노드가 실제로 내놓은 행 수는?

• 5만 행. 두 워커가 나눠 처리했다
• 10만 행. loops 는 재시도 횟수다
• 알 수 없다. 병렬 계획에서는 행 수가 표시되지 않는다
• 20만 행. 표시된 값은 1회 평균이다

통계가 낡은 채로 인덱스만 추가했더니 9.7초가 0.2초가 됐다. 이 상태를 어떻게 봐야 하나?

• 원인이 해결됐다. 인덱스가 없던 것이 문제였다
• 예상은 여전히 틀려 있으므로 같은 사고가 반복된다
• 인덱스가 통계를 대신하므로 ANALYZE 는 필요 없어졌다
• 쓰기 비용만 늘었을 뿐 읽기에는 아무 이득이 없다

update 로 한 컬럼만 바꿨는데 표 크기가 1.7배가 됐다. 이유는?

• 갱신된 행 때문에 인덱스가 통째로 재작성됐기 때문
• 갱신 대상 행을 WAL 에 그대로 복사해 두기 때문
• 새 행 버전을 쓰고 옛 버전을 남겨 두기 때문
• 컬럼 값이 늘어나 TOAST 로 옮겨졌기 때문

VACUUM 이 "dead but not yet removable" 이라고 답했다. 다음에 볼 곳은?

• 열려 있는 트랜잭션 목록
• 그 표의 인덱스 조각화 정도
• autovacuum 의 비용 지연 설정값
• 디스크 여유 공간과 파일시스템 상태

지평선을 붙잡은 세션을 backend_xmin 으로 찾으면 못 찾는 경우가 있다. 왜?

• backend_xmin 은 슈퍼유저에게만 보이는 컬럼이라서
• 통계 수집기가 갱신하는 값이라 몇 초씩 뒤처지기 때문에
• 대기 중인 세션에서는 이 컬럼이 초기화되기 때문에
• 쓰기 트랜잭션은 자기 backend_xid 로 지평선을 잡고, 노는 동안 xmin 은 비어 있어서