DewStream

PostgreSQL: pg_mooncake

※ PostgreSQL: pg_mooncake. 안녕하세요. 듀스트림입니다. 크리스마스 이브입니다. 미리 크리스마스🎄 오늘 포스팅에서는 최근 분석 엔진으로 주목받고 있는 DuckDB를 PostgreSQL 환경에서 네이티브하게 활용할 수 있도록 지원하는 Extension인 pg_mooncake에 대한 내용입니다.1. pg_mooncake ?pg_mooncake는 PostgreSQL 테이블을 Iceberg 기반 컬럼 지향 스토리지로 미러링하여, Sub-second 수준의 최신성(freshness)을 유지하면서 고속 분석 쿼리를 가능하게 하는PostgreSQL Extension입니다. pg_mooncake의 특징컬럼스토어 미러링 구조 pg_mooncake는 PostgreSQL 테이블을 Iceberg 기반 컬..

※ PostgreSQL: PgBouncer. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL의 커넥션 풀러 중 하나인 PgBouncer의 개요부터 설치, 튜닝까지의 내용입니다. 커넥션 풀에 대한 개념 및 내용은 아래 포스팅을 참고 부탁드립니다. PostgreSQL: 커넥션 풀※ PostgreSQL: Connection Pool. 안녕하세요. 듀스트림입니다. 제가 운영 중인 OLTP 시스템은 초당 5,000건 이상의 트랜잭션을 처리하고 있습니다. 이런 환경에서 클라이언트가 매번 DBMS에 직접 연결을 맺dewstream.tistory.com1. PgBouncer ?PgBouncer는 PostgreSQL 전용의 초경량(Connection Pooler) 미들웨어로, 애플리케이션과 PostgreS..

※ PostgreSQL: Managing Parameter Changes in a Patroni Cluster. 안녕하세요. 듀스트림입니다. 요즘은 뭔가 테스트를 하고 싶어도 시간이 없어서 못하는 거 같아요. 7시반 출근 → 21시 퇴근 → 22시 반 집도착 → 씻고 자고 반복~ 오늘 주제는 Patroni Cluster 운영 시 꼭 알아야 되는 내용인 Patroni Cluster를 운영 시, DB 파라미터 변경 방법입니다. (Patroni 공식 문서)PostgreSQL 단독 인스턴스나 다른 HA 도구라면 postgresql.conf 수정 + Reload 또는 Restart로 파라미터를 적용하면 됩니다.하지만 Patroni로 HA Cluster를 운영 중이라면 이야기가 완전히 달라집니다. postgresq..

※ PostgreSQL: Analysis of SELECT Efficiency. 안녕하세요. 듀스트림입니다. 대부분의 서비스에서는 SELECT(Read) 비율이 압도적으로 많습니다. 그렇다면 여기서 의문이 생기겠죠.인덱스를 타긴 타는데, 정말 효율적으로 동작하고 있을까?어떤 테이블과 어떤 쿼리가 Heap 접근을 많이 유발 중일까?Visibility Map, Index-only Scan, 통계 뷰 지표들은 서로 어떻게 연결되는 거지? 오늘 포스팅에서는 로그와 모니터링에 의존하지 않고 시스템 뷰와 통계 지표만으로 SELECT 효율을 해석하는 방법을 알려드리겠습니다.1. SELECT 효율?서비스 쿼리는 기본적으로 응답 시간이 빨라야합니다. SELECT 효율 분석은 여기서 한 뎁스 더 들어가서 다음 내용을 정량..

※ PostgreSQL: DISTINCT ON. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL 고유 확장 기능인 DISTINCT ON에 대한 내용입니다. 알아두면 꽤 편합니다.DISTINCT ON은 표준 ANSI SQL에 속하지 않으며, PostgreSQL 고유 확장 기능입니다.표준 방식은 ROW_NUMBER()를 사용합니다.표준 방식SELECT user_id, event_time, statusFROM ( SELECT user_id, event_time, status, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) AS rn FROM user_events) tWHERE rn = 1; DISTI..

※ PostgreSQL: Streaming-replication Lag. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 PostgreSQL에서 스트리밍 복제 지연 발생 시 분석 방법에 대한 내용입니다. 결론부터 말씀드리면 주로 발생하는 지연 원인은 경험상 아래 정도가 있는 것 같습니다.대부분 비동기 복제 정책 문제 (95% 이상)배치, Autovacuum, 인덱스 재작성 등 피크 타임에 WAL 폭증너무 잦은 체크포인트Primary와 Standby의 스토리지 차이(NVME, SSD, HDD)네트워크 지터1. 어디에서 느린건지 구분▸ 복제 동작은 크게 아래 3단계로 볼 수 있습니다:WAL 생성 → 전송/수신 → 재생(리플레이)→ 이 중 어디가 느린지에 따라 원인이 갈립니다. 1.1 Primary에서 확인-- 세..

※ PostgreSQL: never executed. 안녕하세요. 듀스트림입니다. PostgreSQL 실행계획을 보면 어떤 노드 옆에 "never executed"라는 문구가 표시될 때가 있습니다.이건 꽤 중요한 의미를 가지는 지표라서 오늘 포스팅에서 한번 설명드리겠습니다.1. never executed의 의미never executed는 해당 실행 계획 노드(Plan Node)가 실제 실행 중 단 한 번도 수행되지 않았음을 의미합니다.즉, 실행 계획 상으로는 존재하지만, 런타임 시 조건문이나 상위 노드의 제어 흐름 때문에 해당 노드가 호출되지 않은 것입니다. 예를 들어:EXPLAIN (ANALYZE, BUFFERS)SELECT *FROM orders oWHERE o.id IN ( SELECT id FR..

※ PostgreSQL: ctid. 안녕하세요. 듀스트림입니다. 오늘 포스팅은 지난 포스팅과 연계되는 내용으로 시스템 컬럼인 ctid에 대해 알아보겠습니다. 5.6. System Columns5.6. System Columns # Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot …www.postgresql.org1. ctid?ctid는 PostgreSQL의 각 행(Row) 에 대해 자동으로 부여되는 물리적 위치 식별자입니다.ctid는 해당 튜플이 테이블 파일 내에서 어느 블록의 몇 번째에 저장되어 있는지를 나타내는 시스템 컬럼으로, 다음과 같은 형식을 ..

※ PostgreSQL: Heap Table Structure. 안녕하세요. 듀스트림입니다. 오늘은 또 슥 한 번 읽어두면 좋은 내용인 PostgreSQL의 기본 저장 구조인 힙 테이블에 대한 내용입니다. PostgreSQL의 힙(Heap) 테이블은 PostgreSQL의 기본 저장 구조입니다.힙 테이블은 인덱스 없이 순서 없이 데이터를 저장하며,PostgreSQL의 MVCC 구현에 매우 밀접하게 관련되어 있습니다.1. 힙 테이블의 계층 구조대충 이렇게 생겼습니다.Table (Relation)└── Data File (heap) └── Page (Block, 8KB) └── Line Pointer (Item Identifier) └── Tuple (Row)2. Data..

※ PostgreSQL: Heap Fetch. 안녕하세요. 듀스트림입니다. 오늘은 실행계획에서 볼 수 있는 힙 페치에 대한 내용입니다.1. Heap Fetch란?PostgreSQL은 인덱스를 통해 행의 위치(TID: Tuple ID) 를 알아내고, 그 다음에 테이블의 실제 데이터 블록(heap) 에 접근해서 행 전체를 읽습니다. 이 두 번째 접근이 바로 "Heap Fetch" 입니다. 예를 들어,EXPLAIN (ANALYZE, BUFFERS)SELECT name FROM users WHERE id = 10;→ 이 쿼리가 Index Scan using users_pkey 로 실행된다면 실행계획에 아래와 같은 항목이 붙을 수 있습니다.Index Scan using users_pkey on users (co..