PostgreSQL 파티셔닝

파티셔닝 시리즈 마지막이다. 앞의 두 편이 얻는 것이었다면 이번 편은 잃는 것이다. 파티셔닝을 결정하기 전에 이 목록을 보고 감당할 수 있는지 판단하는 게 맞다. 유니크 제약은 파티션 키를 포함해야 한다 가장 먼저 부딪히는 벽이다. CREATE TABLE orders ( id bigint, created_at timestamptz NOT NULL, PRIMARY KEY (id) ) PARTITION BY RANGE (created_at); ERROR: unique constraint on partitioned table must include all partitioning columns DETAIL: PRIMARY KEY constraint on table "orders" lacks column "created_at" which is part of the partition key. 이유는 구조에 있다. 유니크 인덱스는 파티션마다 따로 만들어진다. 8월 파티션의 인덱스는 8월 파티션 안에서만 중복을 검사한다. id = 100이 8월에도 있고 9월에도 있는지는 아무도 검사하지 않는다. 그래서 PostgreSQL은 처음부터 허용하지 않는다. ...

지난 편에서 파티셔닝의 확실한 이득은 프루닝보다 데이터를 파티션째 버리는 데 있다고 썼다. 이번 편은 그 운영 이야기다. 시간으로 나눈 파티션을 어떻게 만들고, 어떻게 떼어내고, 어디서 사고가 나는지. 파티션은 미리 있어야 한다 행이 들어올 때 그 값에 맞는 파티션이 없으면 실패한다. ERROR: no partition of relation "orders" found for row DETAIL: Partition key of the failing row contains (created_at) = (2026-10-01 00:00:00+00). 10월 1일 자정에 10월 파티션이 없으면 그 순간부터 모든 INSERT가 이 에러다. 월 초 자정에 장애 나는 전형적인 경로다. ...

“테이블이 커서 파티셔닝했다"는 말을 자주 듣는다. 그리고 그 뒤에 “그런데 안 빨라졌다"가 따라오는 경우도 자주 본다. 파티셔닝은 쿼리를 빠르게 하는 기능이 아니다. 조건에 맞는 파티션만 읽게 하는 기능이다. 그 조건이 안 갖춰지면 이득은 없고 비용만 남는다. 파티션 프루닝 주문 테이블을 월별로 나눴다고 하자. CREATE TABLE orders ( id bigint, created_at timestamptz NOT NULL, ... ) PARTITION BY RANGE (created_at); CREATE TABLE orders_2026_08 PARTITION OF orders FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'); CREATE TABLE orders_2026_09 PARTITION OF orders FOR VALUES FROM ('2026-09-01') TO ('2026-10-01'); 이 쿼리는 9월 파티션 하나만 읽는다. ...