7.3 변경과 회귀 검증
Index나 SQL 변경은 한 parameter를 개선하면서 다른 parameter, write workload, replica를 악화시킬 수 있습니다. 변경 전 success와 safety metric을 정합니다.
비교 항목
| 영역 | 지표 |
|---|---|
| Query | p50, p95, p99, rows, timeout |
| Plan | node, estimate factor, buffers, temp, WAL |
| Host | CPU, memory PSI, storage latency |
| Database | TPS, active session, lock, checkpoint |
| Write | WAL bytes, index size, DML latency |
| Replica | lag와 replay |
배포 전략
- Representative parameter set으로 pre-production 비교
CREATE INDEX CONCURRENTLY의 단계와 실패 상태 감시- 작은 traffic canary
- Plan과 query ID 변화 관찰
- 명확한 rollback DDL과 SQL 준비
CREATE INDEX CONCURRENTLY가 실패하면 invalid index가 남을 수 있습니다.
SELECT indexrelid::regclass, indisvalid, indisready
FROM pg_index
WHERE NOT indisvalid OR NOT indisready;
Plan text가 달라졌다는 이유만으로 회귀라고 판단하지 않습니다. 목표 workload의 latency와 resource가 나빠졌는지 확인합니다. PostgreSQL upgrade 전후에는 representative query set과 production 통계 특성을 반영한 dataset으로 비교합니다.