퀴즈: 계획과 지평선

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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