인덱스가 214MB라서 테이블 전체의 절반 크기 정도임
분석가 입장에서는 좋지만, 쓰기 성능 입장에서는 write amplification 문제가 생김
인덱스는 읽기/쓰기 비율에 따라 설계가 달라지고, 그래서 데이터 웨어하우스나 리드 리플리카를 두는 이유가 됨
너무 많은 사용자를 상대하는 경우라면 OLTP DB에 BI/OLAP 인덱스를 두지 않는 게 좋음
PostgreSQL이 clustered index(Oracle의 Index Organized Table)를 지원하면 좋겠다고 생각함
테이블 접근 패턴이 일정하다면 테이블 자체가 인덱스가 되어 write amplification 없이 효율을 얻을 수 있음
첫 번째 예시는 Plan을 enum 타입으로 정의하는 게 더 낫다고 생각함
텍스트보다 가볍고, 잘못된 필터 입력 시 빈 결과 대신 에러로 처리되어 안정적임
훌륭한 글이었음. PostgreSQL과 MySQL을 수십 년 써왔지만, 이 글을 보고도 여전히 가능성의 일부분만 알고 있었다는 걸 느낌
나도 10년 넘게 Postgres를 써왔지만, 문서를 볼 때마다 여전히 표면만 긁고 있는 느낌임. 정말 강력한 시스템임
PostgreSQL은 마치 Emacs 같음. 겉보기엔 단순하지만 사실상 운영체제 수준의 유연함을 가짐
글 마지막에 언급된 MERGE 구문이 가장 흥미로웠음
평소엔 INSERT ... ON CONFLICT DO UPDATE로 upsert를 처리하지만, MERGE는 더 강력하고 다양한 상황에서 쓸 수 있을 것 같음
MERGE는 SQL 표준에 오래전부터 있었지만, Postgres는 MVCC 모델의 비원자성 문제 때문에 도입을 미뤘음 pganalyze 블로그 글에서도 설명되어 있음
개인적으로는 INSERT ... ON CONFLICT를 선호하고, 정말 필요할 때만 MERGE를 쓰며 에러 처리를 신중히 함
Hacker News 의견들
인덱스가 214MB라서 테이블 전체의 절반 크기 정도임
분석가 입장에서는 좋지만, 쓰기 성능 입장에서는 write amplification 문제가 생김
인덱스는 읽기/쓰기 비율에 따라 설계가 달라지고, 그래서 데이터 웨어하우스나 리드 리플리카를 두는 이유가 됨
너무 많은 사용자를 상대하는 경우라면 OLTP DB에 BI/OLAP 인덱스를 두지 않는 게 좋음
테이블 접근 패턴이 일정하다면 테이블 자체가 인덱스가 되어 write amplification 없이 효율을 얻을 수 있음
첫 번째 예시는
Plan을 enum 타입으로 정의하는 게 더 낫다고 생각함텍스트보다 가볍고, 잘못된 필터 입력 시 빈 결과 대신 에러로 처리되어 안정적임
훌륭한 글이었음. PostgreSQL과 MySQL을 수십 년 써왔지만, 이 글을 보고도 여전히 가능성의 일부분만 알고 있었다는 걸 느낌
글 마지막에 언급된
MERGE구문이 가장 흥미로웠음평소엔
INSERT ... ON CONFLICT DO UPDATE로 upsert를 처리하지만,MERGE는 더 강력하고 다양한 상황에서 쓸 수 있을 것 같음MERGE는 SQL 표준에 오래전부터 있었지만, Postgres는 MVCC 모델의 비원자성 문제 때문에 도입을 미뤘음pganalyze 블로그 글에서도 설명되어 있음
개인적으로는
INSERT ... ON CONFLICT를 선호하고, 정말 필요할 때만MERGE를 쓰며 에러 처리를 신중히 함INSERT ... ON CONFLICT가 더 예측 가능함modern-sql.com의 비교 글 참고
COPY INTO를 binary 포맷으로 사용하는 게 가장 빠름. 서버 측 오버헤드가 거의 없음글에서 다루지 않은 BRIN 인덱스가 흥미로웠음
데이터가 단조 증가한다면 매우 작고 빠른 인덱스로 이상적임
예를 들어 서버에서 수신하는 timestamp 데이터처럼 약간 순서가 어긋나는 경우에도 좋음
UUIDv7의 경우
pages_per_range를 조정해야 할 수도 있음hash 인덱스에서 고유 제약을 못 거는 점이 늘 아쉬움
단순히 exclusion constraint로 변환하는 glue 코드만 있으면 해결될 것 같은데, 왜 아직 없는지 궁금함
해시 기반 고유성 검증은 충돌 처리가 안 되기 때문에 인덱스에서 지원되지 않음
제안된 해결책도 같은 문제를 겪음
Postgres는 해시와 실제 값이 모두 일치해야 중복으로 간주함
글 내용이 신선했음. 가상 컬럼과 해시 인덱스가 흥미롭지만, 아직은 생태계에 완전히 통합되지 못한 느낌임
해시 인덱스는 오랫동안 제약이 많았지만 점차 개선 중이며, 자동 고유 제약이 남은 과제임
저장된 생성 컬럼(stored generated column) 을 사용하면 바로 인덱스를 만들 수 있지 않나 생각함
PostgreSQL 14부터 지원되지만, 결과가 물리적으로 저장되어 추가 스토리지를 차지하기 때문임
클라우드로 옮긴 뒤로는 고정 서버 환경에서 pgsql을 직접 다루는 일이 줄었음
글에 나온 SQL 구문 하이라이팅이 내장 기능인지, 아니면 별도 툴인지 궁금함
다만 긴 쿼리 복사 시 줄바꿈 뒤에 자동으로 공백이 붙는 점이 불편함