HOW2026 济南：PostgreSQL 内核调优、连接瓶颈与 AI 落地的实战全景

四月底的济南，山东酒店金色大厅里坐满了来自全球的 PostgreSQL 和 IvorySQL 开发者。HOW2026（Hello Open-source World）不只是又一场数据库会议——中国开源数据库联盟（COSDA）在此正式成立，IvorySQL 作为 PostgreSQL 的 Oracle 兼容分支正在加速出海，而 AI 与数据库的交汇已经从概念讨论进入工程落地阶段。以下是从会议中提炼出的几条硬核技术线索。

Shared Buffers 的炼金术：为什么 Huge Pages 不是可选项

Josef Machytka 的三小时工作坊把 shared buffers 从"调个参数就行"的模糊认知拉到了 Linux 内核实现层面。几个关键事实：

• PostgreSQL 的 shared buffers 底层依赖 Linux tmpfs 文件系统实现共享内存操作。这意味着你在 shared_buffers 里看到的内存页，实际映射关系比想象中更复杂。
• Transparent Huge Pages（THP）对 PostgreSQL 性能是负面的。THP 的内核合并（khugepaged）会在后台异步合并 4KB 小页为 2MB 大页，这个过程与 PostgreSQL 的内存访问模式冲突——数据库经常只修改一页中的少量字节，THP 合并反而引入额外的写时复制开销和延迟尖峰。
• 正确的做法是预留静态 Huge Pages，让 PostgreSQL 在启动时直接分配，避免运行时合并。

实操：为 PostgreSQL 配置静态 Huge Pages

# 1. 查看 PostgreSQL 需要多少大页
# 假设 shared_buffers = 8GB，每页 2MB
# 需要的大页数 = 8GB / 2MB = 4096
# 再加上少量余量用于其他共享内存结构
grep -i huge /proc/meminfo

# 2. 预留大页（以 4096+128=4224 为例）
sudo sysctl -w vm.nr_hugepages=4224

# 3. 持久化配置
echo "vm.nr_hugepages=4224" | sudo tee -a /etc/sysctl.d/99-hugepages.conf
sudo sysctl --system

# 4. 确认 THP 已关闭
sudo sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
# 持久化：在 /etc/rc.local 或 systemd tmpfiles.d 中加入上述命令

# 5. postgresql.conf 中启用大页
# huge_pages = on          # 默认 try，改为 on 强制使用大页，启动失败则说明预留不足
# shared_buffers = 8GB

启动 PostgreSQL 后，用 grep Huge /proc/meminfo 检查 HugePages_Free 是否接近零——如果还有大量空闲大页，说明预留过多或 shared_buffers 配置偏小；如果 PostgreSQL 启动报错无法分配共享内存，则 vm.nr_hugepages 不够。

在高并发场景下，Machytka 强调的另一个要点是：shared_buffers 并非越大越好。超过系统物理内存的 25% 后，checkpoint 和后台写入的压力会反噬吞吐。合理的起点是总内存的 1/4，然后根据实际 checkpoint 频率和写入延迟微调。

连接的多重宇宙：为什么 1000 个连接会让 PostgreSQL 崩溃

Machytka 的另一场演讲直击 PostgreSQL 最被低估的架构瓶颈——连接模型。

PostgreSQL 是进程模型：每个连接 fork 一个独立的后端进程。这意味着：

• 内存开销：每个后端进程至少占用几 MB（work_mem + 本地缓存 + 上下文），1000 个连接就是数 GB 的物理内存，还没算查询本身需要的空间。
• 上下文切换：Linux 内核在数千个进程间调度时，上下文切换的 CPU 开销呈非线性增长。Machytka 展示了连接数从 200 到 2000 时，TPS 不是线性下降，而是在某个拐点后急剧塌陷。
• 物理内存分配映射：进程模型的内存分散在多个独立地址空间，无法像线程模型那样共享缓存，CPU cache miss 率随之上升。

实操：用 pgBouncer 做连接池，把进程数压到可控范围

# /etc/pgbouncer/pgbouncer.ini

[databases]
myapp = host=127.0.0.1 port=5432 dbname=myapp

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt

# 池模式：transaction 级别，事务结束即释放连接回池
pool_mode = transaction

# 最大客户端连接数（可以远大于 PostgreSQL 的 max_connections）
max_client_conn = 2000

# 每个数据库到 PostgreSQL 的默认池大小
default_pool_size = 50
reserve_pool_size = 10
reserve_pool_timeout = 3

# 超时设置
server_idle_timeout = 300
client_idle_timeout = 600

admin_users = pgbouncer_admin
stats_users = pgbouncer_stats

# 启动 pgBouncer
sudo systemctl enable --now pgbouncer

# 在 PostgreSQL 侧，max_connections 只需覆盖池大小 + 少量管理连接
# postgresql.conf
# max_connections = 60   # 50 池连接 + 10 管理/维护连接

关键决策点：pool_mode = transaction 适合大多数 Web 应用——短事务拿连接，事务结束归还。只有需要会话级状态（如临时表、SET 变量跨事务生效）的场景才用 session 模式，但那意味着池大小必须等于峰值并发数，失去了池化的意义。

AI 不是锦上添花：中国视角下的数据库新战场

会议中多条线索指向同一个判断：在中国，AI 与数据库的结合不是技术炫技，而是应对现实压力的工程选择。

多位演讲者提到，中国面临加速老龄化——未来 10-20 年内 60 岁以上人口将占主导，医疗诊断、个性化用药、物流优化等领域的人力缺口需要 AI 补位。中国法院已裁定"因 AI 而解雇员工"为非法行为，整体社会对 AI 的态度比西方更务实、更少恐惧。

从技术落地角度看，几场演讲提供了不同层次的参考：

• Florents Tselai 的警告最值得记住：pgvector 和相似性搜索只是 AI 数据管道的一小部分。真实应用需要更复杂的数据建模——多表关联、时序特征、结构化与非结构化数据的联合查询，这些 PostgreSQL 本身就能做，但需要设计者跳出"向量搜索 = AI 应用"的简化思维。
• 白山和崔鹏的查询优化研究展示了两条路径：用 AI 技术做通用查询优化（白山），以及用 Tree Transformer 做多维特征提取 + 排序学习做计划选择（崔鹏的 QPR + QPSLR）。后者更前沿，但离生产可用还有距离。
• 郑翔的 AI-Native PG 诊断方向更务实——从 DBA 手动排障转向系统主动识别问题。这是运维侧最容易见效的 AI 落地场景。

实操：pgvector 基础搭建——从相似性搜索起步，但别止步于此

-- 1. 安装 pgvector 扩展
CREATE EXTENSION IF NOT EXISTS vector;

-- 2. 创建带嵌入向量的表
CREATE TABLE documents (
    id        SERIAL PRIMARY KEY,
    title     TEXT NOT NULL,
    content   TEXT NOT NULL,
    embedding VECTOR(1536)   -- OpenAI text-embedding-ada-002 维度
);

-- 3. 创建 HNSW 索引（推荐：查询速度快，构建稍慢）
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- 4. 相似性搜索：找最相关的 5 篇文档
-- 先用应用层生成查询文本的 embedding，再传入 SQL
SELECT id, title, content,
       1 - (embedding <=> '[0.002, -0.003, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.002, -0.003, ...]'::vector
LIMIT 5;

-- 5. 别止步于此——结合结构化过滤才是真实场景
-- "最近三个月、类别为医疗、与查询相似的文档"
SELECT id, title,
       1 - (embedding <=> '[0.002, -0.003, ...]'::vector) AS similarity
FROM documents
WHERE created_at >= NOW() - INTERVAL '3 months'
  AND category = 'medical'
ORDER BY embedding <=> '[0.002, -0.003, ...]'::vector
LIMIT 10;

Tselai 的核心观点：第 5 步那种混合查询才是真实需求，而 PostgreSQL 做混合查询比纯向量数据库更有优势——它本来就会做 WHERE 过滤、JOIN、窗口函数。向量搜索只是其中一个子能力。

IvorySQL：Oracle 兼容不是口号，是迁移路径

IvorySQL 是 PostgreSQL 的中国分支，核心卖点是 Oracle 兼容性。会议中 Shawn Yan 展示了它在 AI 工作负载场景的应用，但更实际的价值在于：大量中国企业和海外机构从 Oracle 迁移时，PL/SQL 语法、数据类型、内置包的兼容层能大幅降低改写成本。

目前 IvorySQL 的兼容度还在演进中，如果你评估 Oracle 迁移，建议先用它跑一份现有 PL/SQL 脚本的兼容性测试，而不是假设"完全兼容"。开源意味着你可以直接看兼容层的实现，判断哪些包已覆盖、哪些还是空壳。

其他值得跟进的技术线索

• 李超的 Hacker 心路：第一年做 PostgreSQL 贡献者的真实经历——不是工具问题，是沟通误解和技术判断偏差。对想入门贡献的人，这条经验比任何 patch 教程都更有参考价值。
• Alena Rybakina 的 Vacuum 资源统计 patch：从想法到补丁的架构旅程，核心挑战是在可观测性和性能开销之间找平衡。per-relation vacuum 统计让你能看到哪张表的 vacuum 最吃资源，而不是只看全局指标。
• 任勇的 Zabbix 7.0 PG 监控配置：连接健康、复制延迟、硬件利用率的告警策略——运维侧最实用的那一场。

落地检查清单

从这场会议中可以提炼出几条立即可做的动作：

HOW2026 展示的趋势很清晰：PostgreSQL 的竞争力不再只是"功能丰富的开源数据库"，而是内核调优的深度（shared buffers、连接模型）、AI 数据管道的广度（pgvector + 结构化查询）、以及通过 IvorySQL 等分支覆盖 Oracle 迁移的路径。济南这场会议把这些线索拉到了同一张桌子上——下一步是回到自己的生产环境，逐条验证。