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.

In the following subsections, those are briefly described.

Figure 2.2. Memory architecture in PostgreSQL.

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 shows a list of the major sub-areas. The details of each sub-area will be described in the following chapters.

Table 2.2: Local memory area
sub-area description reference
work_mem The executor uses this area for sorting tuples by ORDER BY and DISTINCT operations, and for joining tables by merge-join and hash-join operations. Chapter 3
maintenance_work_mem Some kinds of maintenance operations (e.g., VACUUM, REINDEX) use this area. Section 6.1
temp_buffers The executor uses this area for storing temporary tables.

In addition, Dynamic Shared Memory (DSM) was implemented in version 9.4 for Parallel Query. It is an on-demand memory space (i.e., it can be allocated as needed and released when no longer required) used for inter-process communication between PostgreSQL processes.

Dynamic Shared Memory (DSM)

DSM is an independent feature that can be used by users to send and receive data between PostgreSQL processes when developing extension modules. For example, Logical replication relies on DSM. the pg_prewarm contribution module also utilizes DSM.

2.2.2. Shared Memory Area

A shared memory area is allocated by a PostgreSQL server when it starts up. This area is also divided into several fixed-sized sub-areas. Table 2.3 shows a list of the major sub-areas. The details will be described in the following chapters.

Table 2.3: Shared memory area
sub-area description reference
shared buffer pool PostgreSQL loads pages within tables and indexes from a persistent storage to this area, and operates them directly. Chapter 8
WAL buffer To ensure that no data has been lost by server failures, PostgreSQL supports the WAL mechanism. WAL data (also referred to as XLOG records) are the transaction log in PostgreSQL. The WAL buffer is a buffering area of the WAL data before writing to a persistent storage. Chapter 9
commit log The commit log (CLOG) keeps the states of all transactions (e.g., in_progress, committed, aborted) for the concurrency control (CC) mechanism. Section 5.4

In addition to the shared buffer pool, WAL buffer, and commit log, PostgreSQL allocates several other areas, as shown below:

  • Sub-areas for the various access control mechanisms. (e.g., semaphores, lightweight locks, shared and exclusive locks, etc)
  • Sub-areas for the various background processes, such as the checkpointer and autovacuum.
  • Sub-areas for transaction processing, such as savepoints and two-phase commit.

and others.