1. 개요PostgreSQL에서 쿼리 성능을 분석하고 최적화하는 두 가지 주요 도구가 있습니다.ANALYZE: 통계 정보를 수집하여 쿼리 플래너가 최적의 실행 계획을 선택할 수 있도록 지원EXPLAIN ANALYZE: 쿼리를 실제 실행하고, 실행 시간이 얼마나 걸리는지, 어떤 방식으로 수행되는지 분석이 두 가지는 데이터베이스 성능 튜닝에서 필수적인 역할을 합니다. 이번 포스팅에서는 ANALYZE와 EXPLAIN ANALYZE의 차이점을 살펴보고, 언제 어떤 도구를 사용해야 하는지 알아보겠습니다. 2. ANALYZE: 통계 정보 업데이트로 쿼리 최적화 📊ANALYZE란?ANALYZE는 테이블의 통계를 수집하고 PostgreSQL의 쿼리 플래너(Query Planner) 가 최적의 실행 계획을 선택할 수 ..

PostgreSQL의 Dead Tuple과 성능 영향 분석1. Dead Tuple이란?Dead Tuple : PostgreSQL에서 삭제(DELETE)되거나 업데이트(UPDATE)된 레코드가 물리적으로 삭제되지 않고 그대로 남아 있는 데이터PostgreSQL은 MVCC(Multi-Version Concurrency Control)를 사용하기 때문에 업데이트가 발생하면 기존 데이터를 즉시 삭제하는 것이 아니라 새로운 버전을 생성하며, 이전 버전은 Dead Tuple로 남음Dead Tuple 생성 과정 예시-- 기존 데이터 삽입INSERT INTO users (id, name) VALUES (1, 'Alice');-- 데이터 업데이트 (기존 데이터를 삭제하고 새로운 데이터 삽입)UPDATE users SET..

VACUUM 설명1. VACUUM의 필요성PostgreSQL에서는 DELETE, UPDATE 후 데이터가 즉시 삭제되지 않음.이로 인해 Dead Tuples가 누적되면서 쿼리 성능이 저하됩니다.이를 해결하기 위해 정기적인 VACUUM 및 ANALYZE가 필요합니다.VACUUM의 역할Dead Tuples 정리 → 디스크 공간 절약쿼리 실행 속도 향상 → 불필요한 데이터를 읽지 않도록 최적화Autovacuum보다 적극적인 성능 최적화 가능VACUUM ANALYZE "user";인덱스 활용 최적화 → SET enable_seqscan = OFF; 설정 후 실행EXPLAIN ANALYZE SELECT * FROM "user" WHERE email = 'a@a.com';Index Scan 적용 확인2. VACUU..

1. 개요PostgreSQL은 MVCC(Multi-Version Concurrency Control)을 사용하여 데이터를 관리MVCC는 트랜잭션 격리성과 동시성을 보장하는 대신, 불필요한 데이터(Dead Tuples)가 쌓이는 문제 유발이를 해결하기 위해 VACUUM을 실행해야함2. VACUUM이 필요한 이유1. MVCC로 인해 삭제된 데이터(Dead Tuples)가 계속 남아 있음PostgreSQL은 데이터를 즉시 삭제하지 않고, 기존 데이터를 ‘Dead Tuple’로 유지이는 트랜잭션 격리성과 동시성을 보장하기 위한 메커니즘예시DELETE FROM users WHERE id = 1;이때 id = 1 데이터를 즉시 삭제하는 것이 아니라, 삭제되었다고 표시된 Dead Tuple로 남아 있음트랜잭션이 롤백..

1. 개요데이터베이스 성능 최적화는 서버 부하를 줄이고 애플리케이션 응답 속도를 높이는 핵심 요소입니다. 이번 글에서는 pg_stat_statements 확장을 활성화하여 쿼리 실행 통계를 수집하고, EXPLAIN ANALYZE를 사용해 느린 쿼리를 분석하고 최적화하는 방법을 다룹니다.수행한 쿼리 최적화 과정User 테이블의 이메일 기반 검색 최적화user_friends_user 테이블의 조인 최적화room 및 user_room 조인 최적화pg_stat_statements를 활용한 가장 실행 시간이 긴 쿼리 분석쿼리 최적화 적용 전후 성능 비교2. pg_stat_statements 확장 활성화 및 설정PostgreSQL에서 쿼리 실행 통계 수집을 위해 pg_stat_statements 확장을 활성화 필요..

1. 왜 PgBouncer를 도입했는가?문제점t2.micro (1vCPU, 1GB RAM) 환경에서 PostgreSQL 직접 연결 방식은 다음과 같은 문제가 발생커넥션 오버헤드: 애플리케이션의 동시 연결 수 증가 시 PostgreSQL이 부하를 견디기 어려움메모리 부족: 커넥션 유지 시 메모리 소비 증가 → OOM(Out of Memory) 발생 가능성 증가트랜잭션 지연: WebSocket 기반의 실시간 애플리케이션에서 다수의 클라이언트 요청을 처리할 때 연결 지연 및 타임아웃 발생2. PgBouncer vs. Pgpool-II 비교PostgreSQL 성능 최적화를 위해 일반적으로 PgBouncer 또는 Pgpool-II를 선택기능 비교PgBouncerPgpool-II주요 기능단순 커넥션 풀링 (Conn..