PostgreSQL의 병렬 집계는 워커가 부분 집계를 하고 리더 하나가 합치는 구조입니다. 그룹이 많으면 그 합치는 단계가 병목이 됩니다. pgEdge의 Andrei Lepikhov가 DSM 공유 해시 테이블로 이 단계를 없애 보고 균등 분포에서 4.8배를 얻었지만, skew에서 0.04배까지 무너졌습니다. 500만 그룹 쿼리로 병목을 직접 재 보고, 프로세스 모델이 어디서 값을 청구하는지 정리합니다.
UUID v4는 값이 완전히 무작위라 B-tree leaf page를 흩어 놓습니다. 상위 비트에 타임스탬프를 담는 UUID v7은 그 문제를 없앱니다. PostgreSQL 18에 내장된 uuidv7()로 100만 행을 넣어 bigserial, v4, v7 세 가지의 index 크기와 leaf 밀도를 직접 재 봤고, 원문 수치가 그대로 재현됐습니다. 대신 생성 시각이 공개된다는 대가가 붙습니다.
한 트랜잭션이 subtransaction을 64개 넘게 만들면 그 트랜잭션만 느려지는 게 아니라 클러스터 전체가 느려집니다. PlanetScale이 공개한 실측에서는 7,200 TPS가 160 TPS까지 떨어졌습니다. PGPROC 캐시 64개 한계와 pg_subtrans SLRU 조회 경로, hot standby 신규 접속까지 막히는 이유, 그리고 지금 우리 클러스터에서 확인할 진단 쿼리를 정리합니다.
PostgreSQL을 Rust로 다시 짓는 pgrust가 v0.2에서 분석 쿼리 성능 주장을 들고 나왔고, 저자가 그 성능이 어디서 나왔는지 단계별로 해설한 글이 Hacker News 상위에 올랐습니다. 행 단위 Volcano executor에서 출발해 batching으로 2.7배, operator fusion, SIMD까지 얹어 20초짜리 집계를 135ms로 줄이는 과정입니다. PostgreSQL 자체의 executor를 이해하는 교재로도 좋은 글이라 정리합니다.
DuckDB가 가을 출시 예정인 v2.0에 비동기 I/O를 넣습니다. 연산 워커와 별도로 블로킹 I/O 전담 스레드 풀을 두고 read-ahead로 요청을 미리 채우는 구조입니다. S3에서 Parquet 읽기 8.2초가 2.8초로, CSV 878초가 45초로 줄었습니다. PostgreSQL 18의 async I/O와 같은 문제를 다른 방식으로 푼 사례라 나란히 놓고 볼 만합니다.
PostgreSQL이 process-per-connection 모델을 지킨 채 처음으로 비동기 I/O를 도입했습니다. sync, worker, io_uring 세 모드의 구조와 트레이드오프, 그리고 cold scan에서 io_uring이 PostgreSQL 17보다 2.7배 빨라진 이유를 살펴봅니다.
Enter 칠 때마다 300ms 느린 프롬프트를 고치려 fsmonitor부터 건드렸다. 결국 범인은 agnoster가 매 렌더마다 git을 7번 spawn하는 구조였고, 근본 해결은 Starship 전환이었다. 측정 방법의 함정까지 포함한 여정 기록.
EXPLAIN ANALYZE를 붙이면 쿼리가 느려진다는 건 알고 있었습니다. PostgreSQL 19에서 RDTSC CPU 명령어로 타이밍 오버헤드를 38% 줄인 이야기입니다.