直播回顾｜中国开发者与PG内核——我们改得动吗？我们贡献了什么？

2026年8月12日，由中国PG分会、IvorySQL社区与TechTalk技术交流社区联合主办的「三十而立・全球时刻——PG 30周年系列直播」第六期圆满举行。本期主题为 "中国开发者与PG内核——我们改得动吗？我们贡献了什么？"。

本期由尚雷担任主持人，嘉宾包括萧少聪、崔鹏、吕海波、杨向博、周煦能五位老师，围绕中国开发者对PG社区的贡献现状、内核修改的难度与可行性、源码学习路径、表膨胀等核心痛点，以及如何参与社区贡献等话题，展开了坦诚而深入的对话。

PG 17 发布时全球贡献者 463 人，其中华人约 43 人，占比接近 10%。相比早期已有显著增长。中国开发者的贡献历程大致分为几个阶段：第一阶段以文档翻译为主；第二阶段（2017 年左右）中国厂商开始在国际会议演讲、成立 PG 分会；第三阶段（2018 年起）华人名字成规模出现在版本致谢名单中；第四阶段出现华人 Committer，国内厂商开始成规模地向国际社区回馈代码。

社区贡献不仅限于提交 Patch 或成为 Committer，还包括 Bug 报告、测试场景构建、文档翻译等。借助 AI 辅助将中文 Bug 描述转化为英文 Issue，是当前降低参与门槛的有效途径。

关于 PG 内核修改，合入社区主干比在自己的分支上修改要困难得多。社区对核心特性的合并持谨慎态度，只要有反对声音就难以推进；这往往导致国内厂商的修改形成硬分叉，难以合入主干。PG 内核代码库约 150 万行，核心代码约 10 万行。阅读源码不应试图通读所有代码，而应采用问题驱动式学习——基于生产中的具体问题，利用 AI 辅助梳理代码链路。

理解数据库的前提是掌握计算机底层原理——从键盘输入数据到最终写入硬盘的完整路径。AI 显著降低了阅读和理解代码的门槛。PG 所有讨论都公开在邮件列表中，可以把讨论链接丢给 AI，快速了解某个改动的前因后果。

表膨胀是 PG 最痛的问题之一。长事务和复制槽未清理会导致严重的表膨胀和索引膨胀。团队通过分区表、控制非必要索引、让更多更新走 HOT 路径等方式进行规避。有团队尝试给 PG 增加异步清理钩子，将表膨胀率从 30-40% 降到 5% 以内。很多内核修改的起点其实是业务里面的真实痛点。

社区并非没有关注表膨胀问题——PG 17 有增量优化，PG 19 支持了原生的在线 VACUUM FULL。但根本性解决方案（如 64 位事务 ID）仍在讨论中。从运维角度，表膨胀可以通过监控、参数调优、定时任务等手段治理。关于迁移，不应期望新数据库完全兼容旧数据库的行为，而应主动适应新数据库的特性。

中国开发者参与社区的两个主要障碍：一是不习惯用邮件列表沟通，二是不习惯用英文表达。这两个问题现在都可以借助 AI 解决——先写好中文再翻译发出去。贡献可以从日常运维中的重复性工作入手，发现 PG 缺失的功能，在 AI 辅助下尝试实现。提 Bug 也是很好的切入点。国内厂商应把员工参与社区贡献纳入 KPI，而不仅仅是靠个人情怀。