2.2. Memory Architecture

Memory architecture in PostgreSQL can be classified into two broad categories:

  • Local memory area: Allocated by each backend process for its own use.
  • Shared memory area: Used by all processes of a PostgreSQL server.

The following subsections provide a brief description of each category.

Figure 2.2. Memory architecture in PostgreSQL.
Section Contents

2.2.1. Local Memory Area

Each backend process allocates a local memory area for query processing. The area is divided into several sub-areas, whose sizes are either fixed or variable.

Table 2.2 lists the primary sub-areas. Further details regarding these areas are provided in the subsequent chapters.

Table 2.2: Local memory area
sub-area description reference
work_mem Used by the executor for sorting tuples in ORDER BY and DISTINCT operations, and for joining tables via merge-join and hash-join operations. Chapter 3
maintenance_work_mem Used by various maintenance operations, such as VACUUM, REINDEX, and index creation. Section 6.1
temp_buffers Used by the executor to store temporary tables for the duration of a session.

In addition, Dynamic Shared Memory (DSM) was introduced in version 9.4 to support Parallel Query.

DSM is an on-demand memory space (allocated as needed and released when no longer required) used for inter-process communication between PostgreSQL processes.

2.2.2. Shared Memory Area

A shared memory area is allocated by the PostgreSQL server during startup. This area is divided into several fixed-size sub-areas. Table 2.3 lists the primary sub-areas, with further details provided in the subsequent chapters.

Table 2.3: Shared memory area
sub-area description reference
shared buffer pool PostgreSQL loads pages from tables and indexes from persistent storage into this area to operate on them directly. Chapter 8
WAL buffer To ensure data integrity against server failures, PostgreSQL employs a Write Ahead Logging (WAL) mechanism. WAL data (also referred to as XLOG records) constitutes the transaction log. The WAL buffer serves as a temporary storage area for WAL data before it is flushed to persistent storage. Chapter 9
commit log The commit log (CLOG) maintains the state of all transactions (e.g., in-progress, committed, aborted) for the Concurrency Control (CC) mechanism. Section 5.4

In addition to these primary areas, PostgreSQL allocates several other sub-areas for specific purposes:

  • Access control mechanisms: For managing semaphores and various locks (e.g., lightweight locks, shared locks, and exclusive locks).
  • Background processes: For coordinating tasks performed by processes such as the checkpointer and autovacuum.
  • Transaction processing: For managing internal states such as savepoints and two-phase commits.