<div id="readability-page-1" class="page"><div>
    <article>
        

        <div>
            <h2 id="소개">소개</h2>

<p>PostgreSQL의 내부 아키텍처를 이해하는 것은 효율적인 데이터베이스 관리와 성능 최적화의 기초입니다. 이 글에서는 PostgreSQL이 내부적으로 어떻게 작동하는지 프로세스 구조, 메모리 구조, 스토리지 구조의 세 가지 핵심 영역을 중심으로 살펴봅니다.</p>

<p>PostgreSQL은 클라이언트/서버 모델을 기반으로 하며, 멀티프로세스 아키텍처를 채택하고 있습니다. 이러한 설계는 안정성과 확장성을 동시에 제공합니다.</p>

<div>

  <h3 id="section">📌 이 글에서 다루는 내용</h3>

  <h4 id="section-1">🔍 핵심 주제</h4>

  <ul>
    <li><strong>프로세스 구조</strong>: Postmaster, Backend Process, Background Workers의 역할과 상호작용</li>
    <li><strong>메모리 구조</strong>: Shared Memory(shared_buffers, WAL buffers)와 Local Memory(work_mem, temp_buffers)</li>
    <li><strong>스토리지 구조</strong>: 데이터 디렉토리, 8KB 페이지 구조, WAL, TOAST 메커니즘</li>
    <li><strong>쿼리 처리 흐름</strong>: Parser → Analyzer → Rewriter → Planner → Executor</li>
  </ul>

</div>



<p>PostgreSQL 아키텍처는 크게 세 가지 계층으로 나눌 수 있습니다:</p>

<pre><code>flowchart TD
    subgraph CLIENT["Client Applications"]
        C1[psql]
        C2[pgAdmin]
        C3[Applications]
    end

    subgraph PROCESS["Process Layer"]
        P1[Postmaster&lt;br/&gt;Main Process]
        P2[Backend&lt;br/&gt;Processes]
        P3[Background Workers&lt;br/&gt;WAL, Autovacuum]
    end

    subgraph MEMORY["Memory Layer"]
        M1[Shared Memory&lt;br/&gt;Shared Buffers]
        M2[Local Memory&lt;br/&gt;work_mem, temp_buffers]
    end

    subgraph STORAGE["Storage Layer"]
        S1[Tables]
        S2[Indexes]
        S3[WAL]
        S4[CLOG]
    end

    CLIENT --&gt; PROCESS
    PROCESS --&gt; MEMORY
    MEMORY --&gt; STORAGE
</code></pre>

<h2 id="2-프로세스-구조-process-architecture">2. 프로세스 구조 (Process Architecture)</h2>

<p>PostgreSQL은 멀티프로세스 아키텍처를 사용합니다. 각 클라이언트 연결은 별도의 프로세스에서 처리됩니다.</p>

<h3 id="21-postmaster-main-process">2.1 Postmaster (Main Process)</h3>

<p>Postmaster는 PostgreSQL의 메인 프로세스로, 다음과 같은 역할을 수행합니다:</p>

<ul>
  <li><strong>서버 시작 및 종료</strong>: 데이터베이스 서버의 생명주기 관리</li>
  <li><strong>클라이언트 연결 수락</strong>: 새로운 연결 요청을 받아 Backend 프로세스 생성</li>
  <li><strong>Background Worker 관리</strong>: 백그라운드 프로세스들의 시작과 감독</li>
  <li><strong>장애 복구</strong>: 자식 프로세스 실패 시 복구 처리</li>
</ul>

<div><pre><code><span># Postmaster 프로세스 확인</span>
ps aux | <span>grep </span>postgres | <span>grep</span> <span>-v</span> <span>grep</span>

<span># 출력 예시</span>
postgres  1234  0.0  0.1  postmaster <span>-D</span> /var/lib/postgresql/data
</code></pre></div>

<h3 id="22-backend-process">2.2 Backend Process</h3>

<p>각 클라이언트 연결마다 하나의 Backend 프로세스가 생성됩니다:</p>

<ul>
  <li><strong>쿼리 파싱</strong>: SQL 문을 파싱 트리로 변환</li>
  <li><strong>쿼리 플래닝</strong>: 최적의 실행 계획 수립</li>
  <li><strong>쿼리 실행</strong>: 실행 계획에 따라 쿼리 수행</li>
  <li><strong>결과 반환</strong>: 클라이언트에 결과 전송</li>
</ul>

<div><pre><code><span>-- 현재 연결된 Backend 프로세스 확인</span>
<span>SELECT</span> <span>pid</span><span>,</span> <span>usename</span><span>,</span> <span>application_name</span><span>,</span> <span>client_addr</span><span>,</span> <span>state</span><span>,</span> <span>query</span>
<span>FROM</span> <span>pg_stat_activity</span>
<span>WHERE</span> <span>backend_type</span> <span>=</span> <span>'client backend'</span><span>;</span>
</code></pre></div>

<h3 id="23-background-worker-processes">2.3 Background Worker Processes</h3>

<p>PostgreSQL은 다양한 백그라운드 프로세스를 통해 시스템을 관리합니다:</p>

<table>
  <thead>
    <tr>
      <th>프로세스</th>
      <th>역할</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>WAL Writer</strong></td>
      <td>WAL 버퍼를 디스크에 기록</td>
    </tr>
    <tr>
      <td><strong>Checkpointer</strong></td>
      <td>체크포인트 수행, 더티 페이지 기록</td>
    </tr>
    <tr>
      <td><strong>Autovacuum</strong></td>
      <td>자동으로 VACUUM 및 ANALYZE 수행</td>
    </tr>
    <tr>
      <td><strong>BGWriter</strong></td>
      <td>백그라운드에서 더티 버퍼를 디스크에 기록</td>
    </tr>
    <tr>
      <td><strong>Stats Collector</strong></td>
      <td>데이터베이스 통계 수집</td>
    </tr>
    <tr>
      <td><strong>Archiver</strong></td>
      <td>WAL 파일 아카이빙</td>
    </tr>
  </tbody>
</table>

<div><pre><code><span>-- Background Worker 프로세스 목록 확인</span>
<span>SELECT</span> <span>pid</span><span>,</span> <span>backend_type</span><span>,</span> <span>state</span>
<span>FROM</span> <span>pg_stat_activity</span>
<span>WHERE</span> <span>backend_type</span> <span>!=</span> <span>'client backend'</span><span>;</span>
</code></pre></div>

<h2 id="3-메모리-구조-memory-architecture">3. 메모리 구조 (Memory Architecture)</h2>

<p>PostgreSQL의 메모리는 공유 메모리(Shared Memory)와 로컬 메모리(Local Memory)로 구분됩니다.</p>

<h3 id="31-공유-메모리-shared-memory">3.1 공유 메모리 (Shared Memory)</h3>

<p>모든 프로세스가 공유하는 메모리 영역입니다:</p>

<h4 id="shared-buffers">Shared Buffers</h4>

<p>데이터 페이지를 캐싱하는 가장 중요한 메모리 영역입니다.</p>

<div><pre><code><span>-- shared_buffers 설정 확인</span>
<span>SHOW</span> <span>shared_buffers</span><span>;</span>

<span>-- 권장 설정: 전체 RAM의 25% (최대 8GB 정도)</span>
<span>-- postgresql.conf</span>
<span>-- shared_buffers = 4GB</span>
</code></pre></div>

<h4 id="wal-buffers">WAL Buffers</h4>

<p>WAL 레코드를 임시 저장하는 버퍼입니다.</p>

<div><pre><code><span>-- wal_buffers 설정 확인</span>
<span>SHOW</span> <span>wal_buffers</span><span>;</span>

<span>-- 일반적으로 shared_buffers의 1/32, 최소 64KB ~ 최대 16MB</span>
</code></pre></div>

<h4 id="clog-buffers">CLOG Buffers</h4>

<p>트랜잭션 커밋 상태를 저장하는 버퍼입니다.</p>

<h3 id="32-로컬-메모리-local-memory">3.2 로컬 메모리 (Local Memory)</h3>

<p>각 Backend 프로세스가 개별적으로 사용하는 메모리 영역입니다:</p>

<h4 id="work_mem">work_mem</h4>

<p>정렬, 해시 조인 등의 작업에 사용되는 메모리입니다.</p>

<div><pre><code><span>-- work_mem 설정 확인 및 변경</span>
<span>SHOW</span> <span>work_mem</span><span>;</span>

<span>-- 세션 단위로 변경 가능</span>
<span>SET</span> <span>work_mem</span> <span>=</span> <span>'256MB'</span><span>;</span>

<span>-- 주의: 쿼리당 여러 개의 정렬/해시 작업이 동시에 수행될 수 있음</span>
<span>-- 총 사용량 = work_mem × 동시 작업 수 × 연결 수</span>
</code></pre></div>

<h4 id="maintenance_work_mem">maintenance_work_mem</h4>

<p>VACUUM, CREATE INDEX, ALTER TABLE 등의 유지보수 작업에 사용됩니다.</p>

<div><pre><code><span>SHOW</span> <span>maintenance_work_mem</span><span>;</span>

<span>-- 권장: 시스템 RAM의 5~10%</span>
<span>-- maintenance_work_mem = 1GB</span>
</code></pre></div>

<h4 id="temp_buffers">temp_buffers</h4>

<p>임시 테이블을 위한 버퍼입니다.</p>

<div><pre><code><span>SHOW</span> <span>temp_buffers</span><span>;</span>

<span>-- 세션에서 임시 테이블을 처음 사용하기 전에만 변경 가능</span>
<span>SET</span> <span>temp_buffers</span> <span>=</span> <span>'128MB'</span><span>;</span>
</code></pre></div>

<h3 id="33-메모리-구조-다이어그램">3.3 메모리 구조 다이어그램</h3>

<pre><code>flowchart TB
    subgraph SHARED["Shared Memory (모든 프로세스 공유)"]
        subgraph BUFFER["Shared Buffer Pool"]
            BP1[Page]
            BP2[Page]
            BP3[Page]
            BP4[Page]
            BP5[...]
        end
        WB[WAL Buffers]
        CB[CLOG Buffers]
        LT[Lock Table]
    end

    subgraph LOCAL["Local Memory (Backend별)"]
        WM[work_mem&lt;br/&gt;Sort/Hash]
        TB[temp_buffers&lt;br/&gt;Temp Tables]
        CC[Catalog Cache]
    end

    SHARED -.-&gt; LOCAL
</code></pre>

<h2 id="4-스토리지-구조-storage-architecture">4. 스토리지 구조 (Storage Architecture)</h2>

<h3 id="41-데이터-디렉토리-구조">4.1 데이터 디렉토리 구조</h3>

<p>PostgreSQL의 데이터는 <code>PGDATA</code> 디렉토리에 저장됩니다:</p>

<div><pre><code>$PGDATA/
├── base/                 # 데이터베이스 파일
│   ├── 1/               # template1 데이터베이스
│   ├── 13445/           # 사용자 데이터베이스
│   └── ...
├── global/              # 클러스터 전체 테이블 (pg_database 등)
├── pg_wal/              # WAL 세그먼트 파일
├── pg_xact/             # 트랜잭션 커밋 상태 (CLOG)
├── pg_stat/             # 영구 통계 데이터
├── pg_tblspc/           # 테이블스페이스 심볼릭 링크
├── postgresql.conf      # 메인 설정 파일
├── pg_hba.conf          # 클라이언트 인증 설정
└── postmaster.pid       # 서버 PID 및 상태 정보
</code></pre></div>

<h3 id="42-페이지-구조">4.2 페이지 구조</h3>

<p>PostgreSQL의 모든 데이터는 8KB 크기의 페이지(블록)로 저장됩니다:</p>

<h4 id="page-layout-8kb-default">Page Layout (8KB Default)</h4>

<table>
  <thead>
    <tr>
      <th>영역</th>
      <th>크기</th>
      <th>설명</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>Page Header</strong></td>
      <td>24 bytes</td>
      <td><code>pd_lsn</code> (WAL 위치), <code>pd_checksum</code>, <code>pd_lower</code>, <code>pd_upper</code></td>
    </tr>
    <tr>
      <td><strong>Item Pointers</strong></td>
      <td>variable</td>
      <td>각 튜플의 위치(offset)와 길이 정보를 저장하는 라인 포인터 배열</td>
    </tr>
    <tr>
      <td><strong>Free Space</strong></td>
      <td>↕ variable</td>
      <td>새로운 Item Pointer(↓)와 Tuple(↑)이 채워지는 빈 공간</td>
    </tr>
    <tr>
      <td><strong>Tuples (Rows)</strong></td>
      <td>grows ↑</td>
      <td>실제 데이터가 저장되는 영역, 페이지 끝에서부터 위로 채워짐</td>
    </tr>
    <tr>
      <td><strong>Special Space</strong></td>
      <td>optional</td>
      <td>인덱스 페이지에서만 사용 (B-tree 메타데이터 등)</td>
    </tr>
  </tbody>
</table>

<div><pre><code><span>-- 페이지 크기 확인</span>
<span>SHOW</span> <span>block_size</span><span>;</span>

<span>-- 테이블의 페이지 수 확인</span>
<span>SELECT</span> <span>pg_relation_size</span><span>(</span><span>'테이블명'</span><span>)</span> <span>/</span> <span>8192</span> <span>as</span> <span>pages</span><span>;</span>
</code></pre></div>

<h3 id="43-힙-튜플-구조-mvcc">4.3 힙 튜플 구조 (MVCC)</h3>

<p>PostgreSQL은 MVCC(Multi-Version Concurrency Control)를 위해 각 튜플에 메타데이터를 저장합니다:</p>

<h4 id="heaptuple-structure">HeapTuple Structure</h4>

<table>
  <thead>
    <tr>
      <th>영역</th>
      <th>크기</th>
      <th>설명</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>HeapTupleHeader</strong></td>
      <td>23 bytes</td>
      <td>튜플 메타데이터 (아래 상세 참조)</td>
    </tr>
    <tr>
      <td><strong>Null Bitmap</strong></td>
      <td>optional</td>
      <td>NULL 값을 가진 컬럼 표시 (컬럼당 1비트)</td>
    </tr>
    <tr>
      <td><strong>User Data</strong></td>
      <td>variable</td>
      <td>실제 컬럼 데이터</td>
    </tr>
  </tbody>
</table>



<table>
  <thead>
    <tr>
      <th>필드</th>
      <th>설명</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>t_xmin</code></td>
      <td>튜플을 <strong>생성</strong>한 트랜잭션 ID</td>
    </tr>
    <tr>
      <td><code>t_xmax</code></td>
      <td>튜플을 <strong>삭제/갱신</strong>한 트랜잭션 ID (0이면 유효한 튜플)</td>
    </tr>
    <tr>
      <td><code>t_cid</code></td>
      <td>트랜잭션 내 커맨드 순서 ID</td>
    </tr>
    <tr>
      <td><code>t_ctid</code></td>
      <td>현재 튜플 위치 또는 업데이트된 새 튜플 위치 (page, offset)</td>
    </tr>
    <tr>
      <td><code>t_infomask</code></td>
      <td>튜플 상태 플래그 (committed, deleted, updated 등)</td>
    </tr>
  </tbody>
</table>

<div><pre><code><span>-- 튜플의 시스템 컬럼 확인</span>
<span>SELECT</span> <span>ctid</span><span>,</span> <span>xmin</span><span>,</span> <span>xmax</span><span>,</span> <span>*</span> <span>FROM</span> <span>테이블명</span> <span>LIMIT</span> <span>5</span><span>;</span>
</code></pre></div>

<h3 id="44-wal-write-ahead-logging">4.4 WAL (Write-Ahead Logging)</h3>

<p>WAL은 데이터 무결성을 보장하는 핵심 메커니즘입니다:</p>

<div><pre><code>트랜잭션 커밋 과정:
1. 변경 내용을 WAL 버퍼에 기록
2. WAL 버퍼를 디스크의 WAL 파일에 동기화 (fsync)
3. 커밋 완료 응답
4. 나중에 체크포인트에서 실제 데이터 페이지를 디스크에 기록
</code></pre></div>

<div><pre><code><span>-- WAL 관련 설정 확인</span>
<span>SHOW</span> <span>wal_level</span><span>;</span>
<span>SHOW</span> <span>max_wal_size</span><span>;</span>
<span>SHOW</span> <span>min_wal_size</span><span>;</span>

<span>-- 현재 WAL 위치 확인</span>
<span>SELECT</span> <span>pg_current_wal_lsn</span><span>();</span>
</code></pre></div>

<h3 id="45-toast-the-oversized-attribute-storage-technique">4.5 TOAST (The Oversized-Attribute Storage Technique)</h3>

<p>큰 데이터를 효율적으로 저장하기 위한 메커니즘입니다:</p>

<div><pre><code><span>-- TOAST 전략</span>
<span>-- PLAIN: TOAST 미사용 (고정 크기 타입)</span>
<span>-- EXTENDED: 압축 후 외부 저장 (기본값)</span>
<span>-- EXTERNAL: 압축 없이 외부 저장</span>
<span>-- MAIN: 압축만 수행, 최대한 메인 테이블에 유지</span>

<span>-- 테이블의 TOAST 테이블 확인</span>
<span>SELECT</span> <span>relname</span><span>,</span> <span>reltoastrelid</span><span>::</span><span>regclass</span>
<span>FROM</span> <span>pg_class</span>
<span>WHERE</span> <span>relname</span> <span>=</span> <span>'테이블명'</span><span>;</span>
</code></pre></div>

<h2 id="5-쿼리-처리-흐름">5. 쿼리 처리 흐름</h2>

<p>클라이언트 쿼리가 처리되는 전체 과정을 살펴봅니다:</p>

<pre><code>flowchart TD
    CLIENT[Client] --&gt;|SQL Query| BACKEND

    subgraph BACKEND["Backend Process"]
        PARSER[Parser] --&gt;|Parse Tree| ANALYZER[Analyzer]
        ANALYZER --&gt;|Query Tree&lt;br/&gt;의미 분석| REWRITER[Rewriter]
        REWRITER --&gt;|뷰/규칙 적용| PLANNER[Planner]
        PLANNER --&gt;|Execution Plan&lt;br/&gt;최적화| EXECUTOR[Executor]
    end

    EXECUTOR --&gt;|Results| CLIENT
</code></pre>

<div><pre><code><span>-- 쿼리 실행 계획 확인</span>
<span>EXPLAIN</span> <span>(</span><span>ANALYZE</span><span>,</span> <span>BUFFERS</span><span>,</span> <span>FORMAT</span> <span>TEXT</span><span>)</span>
<span>SELECT</span> <span>*</span> <span>FROM</span> <span>users</span> <span>WHERE</span> <span>id</span> <span>=</span> <span>1</span><span>;</span>
</code></pre></div>

<h2 id="핵심-포인트">핵심 포인트</h2>

<ul>
  <li><strong>멀티프로세스 아키텍처</strong>: PostgreSQL은 각 연결에 대해 별도의 Backend 프로세스를 생성하여 안정성을 확보합니다</li>
  <li><strong>Shared Buffers</strong>: 가장 중요한 메모리 설정으로, 일반적으로 전체 RAM의 25%를 권장합니다</li>
  <li><strong>WAL</strong>: Write-Ahead Logging을 통해 데이터 무결성과 복구 능력을 보장합니다</li>
  <li><strong>MVCC</strong>: 각 튜플에 트랜잭션 정보를 저장하여 동시성 제어를 구현합니다</li>
  <li><strong>8KB 페이지</strong>: 모든 데이터는 8KB 페이지 단위로 저장되고 관리됩니다</li>
  <li><strong>Background Workers</strong>: Autovacuum, Checkpointer 등의 프로세스가 자동으로 시스템을 관리합니다</li>
</ul>

<h2 id="결론">결론</h2>

<p>PostgreSQL의 아키텍처를 이해하는 것은 데이터베이스 성능 튜닝과 문제 해결의 기초입니다. 프로세스 구조는 안정성을, 메모리 구조는 성능을, 스토리지 구조는 데이터 무결성을 담당합니다.</p>

<p>특히 Shared Buffers, work_mem, WAL 관련 설정들은 시스템 성능에 직접적인 영향을 미치므로, 워크로드 특성에 맞게 적절히 조정해야 합니다. MVCC 메커니즘을 이해하면 VACUUM의 필요성과 트랜잭션 동작 방식을 더 잘 이해할 수 있습니다.</p>

<h3 id="다음-학습">다음 학습</h3>

<ul>
  <li><a href="/postgresql/mvcc-vacuum">MVCC와 Vacuum 메커니즘</a> - PostgreSQL 동시성 제어 심층 분석</li>
  <li><a href="/postgresql/query-planner">쿼리 플래너와 실행 계획</a> - 쿼리 최적화의 핵심</li>
  <li><a href="/postgresql/performance-tuning">PostgreSQL 성능 튜닝</a> - 실무 성능 최적화 전략</li>
  <li><a href="/postgresql/wal-replication">WAL과 복제</a> - 고가용성 구현의 기초</li>
</ul>

        </div>

        
    </article>

    
</div></div>

Orc’s WIKI

Orc Hwang

소개
PostgreSQL의 내부 아키텍처를 이해하는 것은 효율적인 데이터베이스 관리와 성능 최적화의 기초입니다. 이 글에서는 PostgreSQL이 내부적으로 어떻게 작동하는지 프로세스 구조, 메모리 구조, 스토리지 구조의 세 가지 핵심 영역을 중심으로 살펴봅니다.
PostgreSQL은 클라이언트/서버 모델을 기반으로 하며, 멀티프로세스 아키텍처를 채택하고 있습니다. 이러한 설계는 안정성과 확장성을 동시에 제공합니다.
📌 이 글에서 다루는 내용
🔍 핵심 주제
프로세스 구조: Postmaster, Backend Process, Background Workers의 역할과 상호작용
메모리 구조: Shared Memory(shared_buffers, WAL buffers)와 Local Memory(work_mem, temp_buffers)
스토리지 구조: 데이터 디렉토리, 8KB 페이지 구조, WAL, TOAST 메커니즘
쿼리 처리 흐름: Parser → Analyzer → Rewriter → Planner → Executor
1. PostgreSQL 전체 아키텍처 개요
PostgreSQL 아키텍처는 크게 세 가지 계층으로 나눌 수 있습니다:
flowchart TD
    subgraph CLIENT["Client Applications"]
        C1[psql]
        C2[pgAdmin]
        C3[Applications]
    end
    subgraph PROCESS["Process Layer"]
        P1[Postmaster<br/>Main Process]
        P2[Backend<br/>Processes]
        P3[Background Workers<br/>WAL, Autovacuum]
    end
    subgraph MEMORY["Memory Layer"]
        M1[Shared Memory<br/>Shared Buffers]
        M2[Local Memory<br/>work_mem, temp_buffers]
    end
    subgraph STORAGE["Storage Layer"]
        S1[Tables]
        S2[Indexes]
        S3[WAL]
        S4[CLOG]
    end
    CLIENT --> PROCESS
    PROCESS --> MEMORY
    MEMORY --> STORAGE
2. 프로세스 구조 (Process Architecture)
PostgreSQL은 멀티프로세스 아키텍처를 사용합니다. 각 클라이언트 연결은 별도의 프로세스에서 처리됩니다.
2.1 Postmaster (Main Process)
Postmaster는 PostgreSQL의 메인 프로세스로, 다음과 같은 역할을 수행합니다:
서버 시작 및 종료: 데이터베이스 서버의 생명주기 관리
클라이언트 연결 수락: 새로운 연결 요청을 받아 Backend 프로세스 생성
Background Worker 관리: 백그라운드 프로세스들의 시작과 감독
장애 복구: 자식 프로세스 실패 시 복구 처리
# Postmaster 프로세스 확인
ps aux | grep postgres | grep -v grep
# 출력 예시
postgres  1234  0.0  0.1  postmaster -D /var/lib/postgresql/data
2.2 Backend Process
각 클라이언트 연결마다 하나의 Backend 프로세스가 생성됩니다:
쿼리 파싱: SQL 문을 파싱 트리로 변환
쿼리 플래닝: 최적의 실행 계획 수립
쿼리 실행: 실행 계획에 따라 쿼리 수행
결과 반환: 클라이언트에 결과 전송
-- 현재 연결된 Backend 프로세스 확인
SELECT pid, usename, application_name, client_addr, state, query
FROM pg_stat_activity
WHERE backend_type = 'client backend';
2.3 Background Worker Processes
PostgreSQL은 다양한 백그라운드 프로세스를 통해 시스템을 관리합니다:
프로세스
      역할
    
WAL Writer
      WAL 버퍼를 디스크에 기록
    
Checkpointer
      체크포인트 수행, 더티 페이지 기록
    
Autovacuum
      자동으로 VACUUM 및 ANALYZE 수행
    
BGWriter
      백그라운드에서 더티 버퍼를 디스크에 기록
    
Stats Collector
      데이터베이스 통계 수집
    
Archiver
      WAL 파일 아카이빙
    
-- Background Worker 프로세스 목록 확인
SELECT pid, backend_type, state
FROM pg_stat_activity
WHERE backend_type != 'client backend';
3. 메모리 구조 (Memory Architecture)
PostgreSQL의 메모리는 공유 메모리(Shared Memory)와 로컬 메모리(Local Memory)로 구분됩니다.
3.1 공유 메모리 (Shared Memory)
모든 프로세스가 공유하는 메모리 영역입니다:
Shared Buffers
데이터 페이지를 캐싱하는 가장 중요한 메모리 영역입니다.
-- shared_buffers 설정 확인
SHOW shared_buffers;
-- 권장 설정: 전체 RAM의 25% (최대 8GB 정도)
-- postgresql.conf
-- shared_buffers = 4GB
WAL Buffers
WAL 레코드를 임시 저장하는 버퍼입니다.
-- wal_buffers 설정 확인
SHOW wal_buffers;
-- 일반적으로 shared_buffers의 1/32, 최소 64KB ~ 최대 16MB
CLOG Buffers
트랜잭션 커밋 상태를 저장하는 버퍼입니다.
3.2 로컬 메모리 (Local Memory)
각 Backend 프로세스가 개별적으로 사용하는 메모리 영역입니다:
work_mem
정렬, 해시 조인 등의 작업에 사용되는 메모리입니다.
-- work_mem 설정 확인 및 변경
SHOW work_mem;
-- 세션 단위로 변경 가능
SET work_mem = '256MB';
-- 주의: 쿼리당 여러 개의 정렬/해시 작업이 동시에 수행될 수 있음
-- 총 사용량 = work_mem × 동시 작업 수 × 연결 수
maintenance_work_mem
VACUUM, CREATE INDEX, ALTER TABLE 등의 유지보수 작업에 사용됩니다.
SHOW maintenance_work_mem;
-- 권장: 시스템 RAM의 5~10%
-- maintenance_work_mem = 1GB
temp_buffers
임시 테이블을 위한 버퍼입니다.
SHOW temp_buffers;
-- 세션에서 임시 테이블을 처음 사용하기 전에만 변경 가능
SET temp_buffers = '128MB';
3.3 메모리 구조 다이어그램
flowchart TB
    subgraph SHARED["Shared Memory (모든 프로세스 공유)"]
        subgraph BUFFER["Shared Buffer Pool"]
            BP1[Page]
            BP2[Page]
            BP3[Page]
            BP4[Page]
            BP5[...]
        end
        WB[WAL Buffers]
        CB[CLOG Buffers]
        LT[Lock Table]
    end
    subgraph LOCAL["Local Memory (Backend별)"]
        WM[work_mem<br/>Sort/Hash]
        TB[temp_buffers<br/>Temp Tables]
        CC[Catalog Cache]
    end
    SHARED -.-> LOCAL
4. 스토리지 구조 (Storage Architecture)
4.1 데이터 디렉토리 구조
PostgreSQL의 데이터는 PGDATA 디렉토리에 저장됩니다:
$PGDATA/
├── base/                 # 데이터베이스 파일
│   ├── 1/               # template1 데이터베이스
│   ├── 13445/           # 사용자 데이터베이스
│   └── ...
├── global/              # 클러스터 전체 테이블 (pg_database 등)
├── pg_wal/              # WAL 세그먼트 파일
├── pg_xact/             # 트랜잭션 커밋 상태 (CLOG)
├── pg_stat/             # 영구 통계 데이터
├── pg_tblspc/           # 테이블스페이스 심볼릭 링크
├── postgresql.conf      # 메인 설정 파일
├── pg_hba.conf          # 클라이언트 인증 설정
└── postmaster.pid       # 서버 PID 및 상태 정보
4.2 페이지 구조
PostgreSQL의 모든 데이터는 8KB 크기의 페이지(블록)로 저장됩니다:
Page Layout (8KB Default)
영역
      크기
      설명
    
Page Header
      24 bytes
      pd_lsn (WAL 위치), pd_checksum, pd_lower, pd_upper
    
Item Pointers
      variable
      각 튜플의 위치(offset)와 길이 정보를 저장하는 라인 포인터 배열
    
Free Space
      ↕ variable
      새로운 Item Pointer(↓)와 Tuple(↑)이 채워지는 빈 공간
    
Tuples (Rows)
      grows ↑
      실제 데이터가 저장되는 영역, 페이지 끝에서부터 위로 채워짐
    
Special Space
      optional
      인덱스 페이지에서만 사용 (B-tree 메타데이터 등)
    
-- 페이지 크기 확인
SHOW block_size;
-- 테이블의 페이지 수 확인
SELECT pg_relation_size('테이블명') / 8192 as pages;
4.3 힙 튜플 구조 (MVCC)
PostgreSQL은 MVCC(Multi-Version Concurrency Control)를 위해 각 튜플에 메타데이터를 저장합니다:
HeapTuple Structure
영역
      크기
      설명
    
HeapTupleHeader
      23 bytes
      튜플 메타데이터 (아래 상세 참조)
    
Null Bitmap
      optional
      NULL 값을 가진 컬럼 표시 (컬럼당 1비트)
    
User Data
      variable
      실제 컬럼 데이터
    
HeapTupleHeader 상세
필드
      설명
    
t_xmin
      튜플을 생성한 트랜잭션 ID
    
t_xmax
      튜플을 삭제/갱신한 트랜잭션 ID (0이면 유효한 튜플)
    
t_cid
      트랜잭션 내 커맨드 순서 ID
    
t_ctid
      현재 튜플 위치 또는 업데이트된 새 튜플 위치 (page, offset)
    
t_infomask
      튜플 상태 플래그 (committed, deleted, updated 등)
    
-- 튜플의 시스템 컬럼 확인
SELECT ctid, xmin, xmax, * FROM 테이블명 LIMIT 5;
4.4 WAL (Write-Ahead Logging)
WAL은 데이터 무결성을 보장하는 핵심 메커니즘입니다:
트랜잭션 커밋 과정:
1. 변경 내용을 WAL 버퍼에 기록
2. WAL 버퍼를 디스크의 WAL 파일에 동기화 (fsync)
3. 커밋 완료 응답
4. 나중에 체크포인트에서 실제 데이터 페이지를 디스크에 기록
-- WAL 관련 설정 확인
SHOW wal_level;
SHOW max_wal_size;
SHOW min_wal_size;
-- 현재 WAL 위치 확인
SELECT pg_current_wal_lsn();
4.5 TOAST (The Oversized-Attribute Storage Technique)
큰 데이터를 효율적으로 저장하기 위한 메커니즘입니다:
-- TOAST 전략
-- PLAIN: TOAST 미사용 (고정 크기 타입)
-- EXTENDED: 압축 후 외부 저장 (기본값)
-- EXTERNAL: 압축 없이 외부 저장
-- MAIN: 압축만 수행, 최대한 메인 테이블에 유지
-- 테이블의 TOAST 테이블 확인
SELECT relname, reltoastrelid::regclass
FROM pg_class
WHERE relname = '테이블명';
5. 쿼리 처리 흐름
클라이언트 쿼리가 처리되는 전체 과정을 살펴봅니다:
flowchart TD
    CLIENT[Client] -->|SQL Query| BACKEND
    subgraph BACKEND["Backend Process"]
        PARSER[Parser] -->|Parse Tree| ANALYZER[Analyzer]
        ANALYZER -->|Query Tree<br/>의미 분석| REWRITER[Rewriter]
        REWRITER -->|뷰/규칙 적용| PLANNER[Planner]
        PLANNER -->|Execution Plan<br/>최적화| EXECUTOR[Executor]
    end
    EXECUTOR -->|Results| CLIENT
-- 쿼리 실행 계획 확인
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM users WHERE id = 1;
핵심 포인트
멀티프로세스 아키텍처: PostgreSQL은 각 연결에 대해 별도의 Backend 프로세스를 생성하여 안정성을 확보합니다
Shared Buffers: 가장 중요한 메모리 설정으로, 일반적으로 전체 RAM의 25%를 권장합니다
WAL: Write-Ahead Logging을 통해 데이터 무결성과 복구 능력을 보장합니다
MVCC: 각 튜플에 트랜잭션 정보를 저장하여 동시성 제어를 구현합니다
8KB 페이지: 모든 데이터는 8KB 페이지 단위로 저장되고 관리됩니다
Background Workers: Autovacuum, Checkpointer 등의 프로세스가 자동으로 시스템을 관리합니다
결론
PostgreSQL의 아키텍처를 이해하는 것은 데이터베이스 성능 튜닝과 문제 해결의 기초입니다. 프로세스 구조는 안정성을, 메모리 구조는 성능을, 스토리지 구조는 데이터 무결성을 담당합니다.
특히 Shared Buffers, work_mem, WAL 관련 설정들은 시스템 성능에 직접적인 영향을 미치므로, 워크로드 특성에 맞게 적절히 조정해야 합니다. MVCC 메커니즘을 이해하면 VACUUM의 필요성과 트랜잭션 동작 방식을 더 잘 이해할 수 있습니다.
다음 학습
MVCC와 Vacuum 메커니즘 - PostgreSQL 동시성 제어 심층 분석
쿼리 플래너와 실행 계획 - 쿼리 최적화의 핵심
PostgreSQL 성능 튜닝 - 실무 성능 최적화 전략
WAL과 복제 - 고가용성 구현의 기초

PostgreSQL 아키텍처 심층 분석

댓글