카테고리

스토리

AI가 짜준 코드를 어디까지 기계한테 검증시킬 수 있을까?

처음에는 검증 충분성을 기계가 결정적으로 판정하게 만들려 했다. 그런데 사람이 하던 그 판단은 원래 확률적이었다. 그래서 갈라야 할 것은 무엇을 고정하고 무엇을 맡길 것인가였다. 고정할 자리에는 경계와 검사를 두고, 맡길 자리에는 판단할 재료를 준다. 다만 자기를 심판하는 자리 하나는 기계가 붙잡아야 한다.

데이터베이스 인덱스 ⑥: 운영과 한계

인덱스 시리즈 마무리. 운영 환경의 인덱스 작업은 DDL이 DB를 멈출 수 있다는 사실에서 출발합니다. CREATE INDEX CONCURRENTLY의 4단계 phase와 제약, 장기 트랜잭션이 클러스터 전반의 VACUUM/IOS에 미치는 영향, 인덱스 bloat과 REINDEX, 수십억 행을 위한 파티셔닝/샤딩, Bloom Filter, 그리고 6가지 안티패턴까지 1차 자료 기준으로 정리합니다.

데이터베이스 인덱스 ③: Covering Index와 Index-Only Scan

plan에 Index Only Scan이 잡혔다고 진짜 IOS는 아닙니다. PostgreSQL의 IOS는 covering(쿼리 컬럼이 인덱스에)과 visibility(VM all-visible) 두 단계 조건을 모두 만족해야 Heap Fetches가 0이 됩니다. INCLUDE 절은 covering을, VACUUM은 visibility를 충족시키는 도구입니다. INCLUDE의 leaf-only 저장 메커니즘과 인덱스 타입별 IOS 지원, 그리고 PG12 이전 insert-only Mandrill 함정까지 다룹니다.

데이터베이스 인덱스 ②: 스캔의 종류와 옵티마이저의 선택

인덱스가 있다고 모든 쿼리가 같은 방식으로 그 인덱스를 쓰는 것은 아닙니다. PostgreSQL의 Sequential / Index / Index-Only / Bitmap Scan 4가지 전략과, 옵티마이저가 통계 기반 셀렉티비티 추정으로 그 중 하나를 고르는 메커니즘을 1차 자료 기준으로 정리합니다. correlation, work_mem, BitmapAnd, Index Cond vs Filter까지.

데이터베이스 인덱스 ①: 인덱스 기초와 EXPLAIN 읽기

인덱스는 검색용 보조 자료구조이고, 그 인덱스를 쓸지 말지를 결정하는 것은 옵티마이저입니다. 옵티마이저의 결정을 검증하는 도구가 EXPLAIN이고, 실측까지 더하는 것이 EXPLAIN ANALYZE입니다. cost가 임의 단위라는 점, 추정과 실측의 격차가 진단의 핵심 신호라는 점, 인덱스가 있어도 안 쓰이는 4가지 패턴까지 1차 자료 기준으로 정리합니다.