🐘 PostgreSQL: 남들은 잘 안 쓰는 변태적인(?) 최적화 팁

Source: Unconventional PostgreSQL Optimizations

🎣 Hook: "인덱스 걸었는데 왜 느리죠?"

쿼리 튜닝은 예술입니다. 하지만 때로는 정석적인 방법(B-Tree 인덱스 추가)만으로는 한계에 부딪힙니다. 인덱스 크기가 너무 커져서 오히려 성능을 갉아먹기도 하죠.

여기, Haki Benita가 제안하는 "비상식적이지만 효과적인" 최적화 방법 3가지를 소개합니다.

개발자의 실수로 존재하지 않는 값을 조회할 때가 있습니다. (예: plan='Pro'인데 실제로는 plan='pro'로 저장됨) 보통은 DB가 바보처럼 테이블을 다 뒤집니다(Full Scan). 하지만 Check Constraint를 걸어두면?

ALTER TABLE users ADD CONSTRAINT check_plan CHECK (plan IN ('free', 'enterprise', 'pro'));
-- 그리고 설정 켜기
SET constraint_exclusion = on;

이제 DB는 plan='Pro' 쿼리가 오면 "어? 제약조건에 없네?" 하고 검색 자체를 시도하지 않습니다(0ms).

created_at 같은 타임스탬프 컬럼에 인덱스를 걸면 크기가 엄청납니다. 하지만 대부분의 조회는 '날짜(Day)' 단위로 이루어진다면?

-- 전체 타임스탬프 대신 날짜만 인덱싱
CREATE INDEX idx_sold_at_date ON sales ((date_trunc('day', sold_at AT TIME ZONE 'UTC')));

이렇게 하면 인덱스 크기가 3배 이상 줄어듭니다. PG 엔진이 중복된 날짜 값들을 압축(Deduplication)하기 때문입니다.

"URL 같은 긴 문자열의 중복을 막고 싶다." 보통 UNIQUE 제약조건을 걸면 B-Tree 인덱스가 생성됩니다. 하지만 URL은 너무 길어서 인덱스 용량을 많이 차지합니다.

이때 Hash Index를 쓰면 획기적으로 줄일 수 있습니다. (B-Tree 대비 5배 작음)

-- Exclude Constraint를 이용한 해시 유니크
ALTER TABLE urls ADD CONSTRAINT urls_unique_hash EXCLUDE USING HASH (url WITH =);

이제 URL 자체를 저장하는 게 아니라, 해시값만 저장하므로 용량이 획기적으로 줄어듭니다.

내 DB 스키마를 던져주고 "비상식적인 최적화"를 맡겨보자. "이 테이블 스키마(CREATE TABLE...)를 봐줘. URL 컬럼이 있는데 중복 방지가 필요해. B-Tree 인덱스 대신 Hash 인덱스로 최적화하는 SQL 쿼리를 짜주고, 장단점을 설명해줘."

"Unconventional Linter": pg_dump 스키마 파일을 넣으면, 이런 '변태적인' 최적화 팁을 적용할 수 있는 컬럼을 찾아서 제안해주는 CI/CD 도구. (Check Constraints 활용 기회 포착 등)

카테고리: tech_deep_dive, ``