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 descibed.
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.
|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.
|Some kinds of maintenance operations (e.g., VACUUM, REINDEX) use this area.
|The executor uses this area for storing temporary tables.
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.
|shared buffer pool
|PostgreSQL loads pages within tables and indexes from a persistent storage to this area, and operates them directly.
|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.
|The commit log (CLOG) keeps the states of all transactions (e.g., in_progress, committed, aborted) for the concurrency control (CC) mechanism.
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.