PostgreSQL 核心特性全景：12 大功能的设计动因、实现原理与版本演化

本文是「PostgreSQL 源码系列」设计篇。同系列前文：

• PostgreSQL 前世今生：从 1986 Berkeley 实验室到 2025 全球基础设施，一条开源数据库的 39 年演化史
• PostgreSQL 元数据存储机制：从磁盘文件到内存缓存，pg_class 撑起的整个系统表体系
• PostgreSQL 从 postgres 二进制到生产级守护：最外层模块与启动全流程
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 事务生命周期：从 BEGIN/COMMIT 到 CLOG 一条链路
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 18 并行 Worker 机制全解
• PostgreSQL Background Worker 全解
• PostgreSQL 内核开发：读取一张表的 9 步标准流程与缓存全景

很多人会问：PostgreSQL 现在到底有什么功能？

如果你只看 SQL 标准支持度，PG 12+ 已经超过大部分商业数据库；如果你看扩展生态，Citus / TimescaleDB / PostGIS / pgvector 这些把 PG 推到了 OLTP / 分析 / 时序 / GIS / AI 五个赛道的中心位置。

但 PostgreSQL 真正的特点是：每个核心特性都有自己的历史。不是一个全局架构师一次性设计的产物，而是 39 年里、几百位贡献者、几千封 pgsql-hackers 邮件讨论沉淀下来的。

本文回答 3 个问题：

1. 一个特性怎么进入主线？需要哪些不同的生命周期阶段？
2. PG 12 大核心特性，分别为什么而设计、怎么实现、走过哪些路？
3. PG 的设计哲学是什么？未来 5 年会动哪几条线？

12 大特性按版本号组织：

10 大主特性 + 2 个补充特性 = 12 大。每个特性都是一件独立的“发生了什么”故事。

一、一个特性怎么进入 PostgreSQL 主线

在跳到具体特性之前，先看看 PG 社区设计哲学。

1.1 一个特性从想法到 merge 的 5 个阶段

1.2 CommitFest：PG 的“移动 PR review”

CF 的作用：开发者提交 patch → committer 随便抓一个 patch review → 轮转 reviewer，保证 patch 不是“一人被投票”通过。提交者被 random reviewer 卡住是常态。

1.3 设计哲学 3 道关卡

每个特性要进入主线，必须在三个哲学层达成共识：

PG 的“Code 说”：是能“会说“SQL”” 还是“能说会让 X 在回滚”，决定这个特性能不能进入主线。MERGE 2003 SQL+ 2014 SQL+ 在侏儒纪；8.4 window functions 2003 SQL+ 10+ 逻辑复制 + 15 MERGE 在 SQL++。

二、PG 12 大核心特性 动因 + 设计 + 实现 + 演化

接下来逐个介绍 12 大特性。每个特性都是一个独立故事。

2.1 WAL（预写日志）— 7.1 引进，Crashing safety 的起点

2.1.1 动因

在 WAL 之前，PG 7.0 以前的版本 crash 后只能 “靠 pg_resetxlog 修复” —— 是手工猜想的，不可靠。
动机：需要一种 “集成式 crash safety” 机制 — WAL （Write-Ahead Log）。

2.1.2 设计原理

PGL 设计思路：

1. 任何 page 在被刷到磁盘之前，对应的 WAL 记录必须先 fsync（原设计）。
2. **PG 从 7.1 起使用 “ WAL 从 XLogWrite → XLogFlush → BackgroundWriter “ 的 3 层架构 “。
3. 9.0 起引入 “ group commit “ （多项事务合并刷）
4. 9.6 起引入 “ group commit + wal_receiver 限速 “

2.1.3 演化版本

9.0 是 WAL 变革性改造 —— 现在说 WAL 还是为 「PG streaming replication / logical replication / 备机 replay 」 服务的。

2.1.4 周边文件

src/backend/access/transam/xlog.c      // WAL 核心
src/backend/access/transam/xlogreader.c  // 备机 replay
src/backend/access/transam/xlogrecovery.c // PITR
src/backend/access/transam/xlogutils.c   // WAL record 处理
src/include/access/xlog.h               // WAL 数据结构
src/include/access/xlogreader.h         // WAL reader 接口

2.1.5 优势 / 代价

WAL 起点是 PG 最重架构。未来 5 年不会变。

2.2 PITR (Point-in-Time Recovery) — 8.0 引进

2.2.1 动因

7.1 加入了 WAL，但只能从 crash 恢复点还原。动机：能从 “任意时间” 到 “上一次备份点” 重做 WAL，PITR（Point-In-Time Recovery）。

2.2.2 设计原理

PG 8.0 PITR 设计是：

1. 全量备份 (pg_basebackup) + WAL archive
2. 从恢复点 replay WAL 到 recovery_target_time / recovery_target_xid / recovery_target_name
3. 完成恢复后，集群跳为普通 primary

2.2.3 演化版本

2.2.4 关键 GUC

-- 8.0 起
restore_command = 'cp /var/lib/pgwal/%f %p'
recovery_target_time = '2026-09-29 12:00:00'
recovery_target_xid = '1234567'
recovery_target_name = 'before_migration'
recovery_target_action = 'pause'  -- 8.4 起

-- 13 起
archive_cleanup_command = 'pg_archivecleanup ...'

-- 17 起（增量）
pg_basebackup --incremental=/path/to/manifest

2.3 Streaming Replication (流复制) — 9.0 引进

2.3.1 动因

8.x 已有 PG/DR 能力是 “copy / rsync / Slony-I (external tool)”。动机：能轻松、完备、内置。

2.3.2 设计原理

9.0 起 streaming replication 设计：

1. primary 不断发送 WAL 到 standby（wal_sender）
2. standby 接收后写 standby WAL → replay（wal_receiver / startup process）
3. standby 可以处于两种模式：
   • **Hot Standby (9.0+)**：可以读
   • **Warm Standby (9.0-)**：不能读

2.3.3 同步 / 异步

synchronous_commit = on | off | remote_write
synchronous_standby_names = '*'

2.3.4 演化版本

2.4 JSONB — 9.4 引进

4.1 动因

9.2 (2012) 加了 JSON (text-based)，但不能索引。动机：为互联网时代的 半结构化数据 提供一种 “可索引、可计算的二进制存储” —— **JSONB (Binary JSON)**。

4.2 JSON vs JSONB

4.3 索引策略

-- JSONB + GIN（默认 ops 包含 key 存在判断）
CREATE INDEX idx_users_data ON users USING GIN (data jsonb_path_ops);

-- JSONB + B-tree（特定表达式）
CREATE INDEX idx_users_country ON users ((data->>'country'));

4.4 演化版本

2.5 Parallel Query（并行查询）— 9.6 引进

5.1 动因

PG 8.x 9.x 之前 单进程 + 单连接 的执行模型，在多核机器上只能利用 1 核。动机：为多核架构提供 轻量并行 worker 模型。

5.2 设计原理

worker 不是独立 server / bgworker —— 是 postmaster fork 出来执行同一个 PL 的进程。详见 PostgreSQL 18 并行 Worker 机制全解

5.3 GUC

max_parallel_workers = 8         -- 所有进程开始可用的 worker
max_parallel_workers_per_gather = 2  -- 每个 Gather 能用的 worker
max_parallel_maintenance_workers = 2  -- VACUUM / CREATE INDEX 可用的 worker
parallel_tuple_cost = 0.1
parallel_setup_cost = 1000
min_parallel_table_scan_size = 8MB
min_parallel_index_scan_size = 512kB

5.4 演化版本

2.6 Logical Replication（逻辑复制）— 10 引进

6.1 动因

物理 WAL 在 streaming repl 上虽然能同步所有 DML，但 不能 跨版本 / 跨 schema / 跨表过滤。动机：需要一种 逻辑 级别的复制 —— Logical Replication。

6.2 设计原理

pgoutput 是协议 + 插件 —— 是逻辑复制的 “output plugin / apply worker” 两边的逻辑复制操作。

6.3 关键能力

-- DDL replicate (10+)
ALTER SUBSCRIPTION sub_x REFRESH PUBLICATION;

-- Row filter (15+)
CREATE PUBLICATION pub_a FOR TABLE t WHERE (id > 100);

-- Column list (15+)
CREATE PUBLICATION pub_a FOR TABLE t (id, name);

-- conflict detection (16+)
-- Sub 端 enable on_conflict

6.4 演化版本

2.7 Declarative Partitioning — 10 引进

7.1 动因

PG 9.x 以前分区是 “用继承表 + 仿触发器手工实现”，太多代码。动机：在 catalog 层 为表呈现 “是一个子表”。

7.2 设计原理

7.3 Partition 4 种策略

7.4 演化版本

2.8 JIT Compilation — 11 引进

8.1 动员说还是动因

PG 10 以前 executor 是 逐行 (tuple-at-a-time) 的 volcano 模型。动机：为 表达式频繁执行的 OLAP 提供 JIT —— 11 引进 JIT（LLVM ORC）

8.2 JIT 架构

8.3 JIT GUC

jit = on                            -- 全局开关
jit_above_cost = 100000             -- 表达式 cost 超过这个值启用 JIT
jit_inline_bitmap = 50000           -- inline 调用的子方
jit_optimize_bitmaps = 500000       -- 超额优化 阈值
jit_dump_bitmaps = 0                -- 不支持

8.4 演化版本

**JIT 入口在 src/backend/jit/llvm/**：是 LLVM 运行时 的 OTEL 版本，为 PG 量身定制。

2.9 Pluggable Table Access Method — 12 引进

9.1 动员说还是动因

PG 18 以前访问表是 TBH HeapTuple（硬编码），不能像 MySQL / Oracle 那样插入 columnar / zheap。动机：为 PGLite / zheap / columnar / 未来 bit-engine 提供 “是插入 storage”

9.2 AM 架构

9.3 AM 必须实现的接口

9.4 演化版本

columnar AM 实验状态，在 PG 18 / 19 中测试。详见 https://github.com/citusdata/citus / zheap。

2.10 MERGE — 15 引进

10.1 动因

MERGE 是 SQL 2003 标准，但 PG 一直未提供。动机：9.5 ON CONFLICT 只能 UPSERT，不能 DELETE/UPDATE 混合。

10.2 语法

MERGE INTO target t
USING source s
ON t.id = s.id
WHEN MATCHED AND s.flag = 'a' THEN
    UPDATE SET name = s.name
WHEN MATCHED THEN
    DELETE
WHEN NOT MATCHED THEN
    INSERT (id, name) VALUES (s.id, s.name);

10.3 演化版本

MERGE 进入主线用了 18 个月 CF review —— 是 PG 15 release manager 集齐 6 轮补丁后的成果。

2.11 Full Text Search — 8.3 引进

11.1 动因

PG 8.2 以前全文检索要靠 LIKE ‘%xxx%’（不索引）或外部工具（tsearch2 / OpenFTS）。动机：内置 TSearch2 逆索引。

11.2 架构

11.3 演化版本

2.12 Foreign Data Wrappers — 9.1 引进

12.1 动因

PG 8.x 以前不能跨数据源查询。动机：用 SQL 直接查 外部数据源（MySQL / MongoDB / Oracle / 文件）。

12.2 FDW 接口

// 必须实现的 6 个 Handler 接口
PG_FUNCTION_INFO_V1(my_fdw_handler);
Datum my_fdw_handler(PG_FUNCTION_ARGS) {
    FdwRoutine *routine = makeNode(FdwRoutine);
    routine->GetForeignRelSize = my_GetForeignRelSize;
    routine->GetForeignPaths = my_GetForeignPaths;
    routine->GetForeignPlan = my_GetForeignPlan;
    routine->BeginForeignScan = my_BeginForeignScan;
    routine->IterateForeignScan = my_IterateForeignScan;
    routine->EndForeignScan = my_EndForeignScan;
    ...
}

12.3 核心 FDW 生态

12.4 演化版本

三、PG 12 大特性进化总表

四、PG 设计哲学：6 个原则

4.1 6 个原则详解

4.2 PG vs MySQL 决策原则对比

五、12 大特性在 PG 18 中的状态

六、总结：PG 设计的 6 个心智模型

源码引用索引

• src/backend/access/transam/xlog.c — WAL 核心
• src/backend/access/transam/xlogrecovery.c — PITR
• src/backend/replication/walsender.c — streaming repl sender
• src/backend/replication/walreceiver.c — streaming repl receiver
• src/backend/replication/logic/ — logical repl (10+)
• src/backend/access/heap/heapam.c — heap AM
• src/backend/jit/llvm/ — JIT (11+)
• src/include/catalog/pg_am.h — AM catalog
• src/include/executor/executor.h — executor 抽象
• src/include/foreign/fdwapi.h — FDW 接口
• src/include/tsearch/ — full text search
• src/include/utils/jsonb.h — JSONB 类型

同系列前文

• PostgreSQL 前世今生：从 1986 Berkeley 实验室到 2025 全球基础设施，一条开源数据库的 39 年演化史
• PostgreSQL 元数据存储机制：从磁盘文件到内存缓存，pg_class 撑起的整个系统表体系
• PostgreSQL 从 postgres 二进制到生产级守护：最外层模块与启动全流程
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 事务生命周期：从 BEGIN/COMMIT 到 CLOG 一条链路
• PostgreSQL 18 并行 Worker 机制全解
• PostgreSQL Background Worker 全解
• PostgreSQL 内核开发：读取一张表的 9 步标准流程与缓存全景