Hacker News 의견들

• PostgreSQL 공식 문서가 정말 잘 쓰여 있고 읽는 재미도 있어서 공유함
  PostgreSQL Indexes 소개 문서

• 다중 컬럼 인덱스 부분이 내가 배웠던 방식과 거의 같음
  하지만 최신 PostgreSQL 버전에서도 여전히 그런지 궁금했음
  예전에 세 번째 예시와 비슷한 쿼리에서 bitmap index scan이 사용되는 걸 봤는데, 그때부터 기존의 ‘정설’을 다시 생각하게 되었음
  참고로 인덱스 관련해서는 Use The Index, Luke 사이트와 책이 팀 전체가 읽을 만한 고전 자료라고 생각함

  • PostgreSQL 18에서는 index skip scan이 추가되어 이제는 다중 컬럼 인덱스의 하위 컬럼만으로도 효율적인 검색이 가능해졌음
    이전 버전에서도 가능은 했지만, 그땐 전체 인덱스 스캔이 필요해서 비효율적이었음
    관련 영상: YouTube 링크
  • bitmap index scan은 데이터가 있을 가능성이 있는 페이지를 좁혀주지만, 실제 조건 검증은 다시 해야 해서 일반 인덱스 스캔보다 성능이 떨어짐

• PostgreSQL에서 incremental view maintenance를 기본 지원하면 좋겠다고 생각함
  이는 인덱스처럼 기본 데이터가 바뀔 때 자동으로 갱신되지만, 특정 뷰에 한정되지 않고 임의의 뷰에도 적용되는 개념임

  • 이건 트랜잭션 처리가 얽혀 있어서 꽤 어려운 문제임
    Noria, Materialize, Apache Flink, GCP Continuous Queries, Spark Streaming Tables, Delta Tables, ClickHouse streaming tables, TimescaleDB, ksqlDB, StreamSQL 등 관련 프로젝트가 많음
    PostgreSQL에서는 최근에 pg_ivm이라는 확장이 이 문제를 다루기 시작했음
  • 시계열 데이터라면 TimescaleDB의 continuous aggregates 기능이 이미 이런 역할을 함

• B-tree vs Hash 인덱스 논의가 흥미로움
  많은 사람들이 ID 컬럼은 hash가 낫다고 생각하지만, 실제로는 기본 B-tree가 더 효율적임
  특히 거의 순차적인 값 삽입에서는 트리 구조가 더 유리함
  다만 이번에 언급된 블로그 글에서는 반대로 hash가 벤치마크에서 이겼다고 함

• 이번 글의 타이밍이 좋았음
  다중 컬럼 인덱스의 leading column 규칙은 항상 헷갈렸는데, bitmap index scan 덕분에 예전만큼 치명적이지 않게 되었음
  PostgreSQL 18의 skip scan 기능은 기존의 상식을 크게 바꾸므로, 예전 버전 기준으로 배운 사람이라면 정신 모델 업데이트가 필요함

• PostgreSQL용 자료로 정말 멋진 글이라고 생각함
  B-tree 인덱스 관련해서는 예전부터 Use The Index, Luke를 자주 참고해왔음

• 필독서라고 생각함
  단순한 입문서 수준을 넘어서 깊이 있으면서도 내부 구조를 다루지 않는 한 충분히 읽기 쉬움

• 이런 단순하고 겸손한 글쓰기 스타일이 마음에 듦
  지식을 직접적으로 전달하는 방식이 좋음