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

一、活动概况

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

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

二、嘉宾阵容

• 主持人：尚雷：PostgreSQL & Oracle ACE，IvorySQL 专家顾问委员，PostgreSQL 分会南京分会会长，TechTalk 技术交流社区主理人，公众号“尚雷的驿站”主理人。
• 萧少聪：「Dataer 数人」公众号主理人。Cortrix.AI语义存储项目联合创始人。前 PostgreSQL 分会会长及中文社区主席，IvorySQL 专家顾问委员，曾先后任职阿里云 RDS 产品高级专家、华为存储产业营销专家。专注于数据库技术、AI 数据处理、开源技术发展。
• 崔鹏：PostgreSQL ACE，计算机博士，10 年 以上数据库经验，ORACLE OCM + PostgreSQL ACE 双认证，海能达通信 DBA 总监，公众号“CP 的 PostgreSQL 厨房”主理人。
• 吕海波：北京大学企业导师，易景科技首席研究员。PostgreSQL ACED，IT 知识刺客公众号主笔，美创科技技术顾问。从事 IT 技术工作 30 年，曾就职于阿里巴巴、京东、ebay/paypal 等国内外知名科技企业，从事数据库管理与研究工作。连续 5 年为北大硕士研究生讲授数据库内核架构与开发、并指导部分学生论文。公众号“IT 知识刺客”主理人。
• 杨向博：PostgreSQL ACE，PG 分会西安用户组负责人，公众号“PostgreSQL 运维之道”主理人。
• 周煦能：资深 PostgreSQL 内核工程师、PostgreSQL 19 版本核心贡献者，瀚高股份资深内核研发专家。

三、直播内容回顾

板块一：中国开发者到底贡献了多少？

PG 17发布时全球贡献者463人，其中华人约43人，占比接近10%。相比早期已有显著增长——PG刚进入中国时，国内几乎没有内核层面的贡献者。

中国开发者的贡献历程大致分为几个阶段：第一阶段以文档翻译为主；第二阶段（2017年左右），中国厂商开始在国际会议演讲，成立PG分会；第三阶段（2018年起），华人名字成规模出现在版本致谢名单中；第四阶段，出现华人Committer，国内厂商开始成规模地向国际社区回馈代码。

社区贡献不仅限于提交Patch或成为Committer，还包括Bug报告、测试场景构建、文档翻译等。国内使用场景的复杂程度有时超出国际社区的想象，如果不主动提交Issue，国际社区就不知道这些需求的存在。借助AI辅助将中文Bug描述转化为英文Issue，是当前降低参与门槛的有效途径。

板块二：PG内核——我们改得动吗？

关于PG内核修改，合入社区主干比在自己的分支上修改要困难得多。中国开发者近年来的贡献在增加，从之前没有华人Committer到现在已有入选者，但社区核心决策层中仍没有国人面孔，话语权的提升仍需时间。

社区对核心特性的合并持谨慎态度，只要有反对声音就难以推进；而企业可以根据自身考量决定是否接受改动代价，这往往导致国内厂商的修改形成硬分叉，难以合入主干。

PG内核代码库约150万行，核心代码约10万行。阅读源码不应试图通读所有代码，而应采用问题驱动式学习——基于生产中的具体问题，利用AI辅助梳理代码链路。也可以从高频函数入手，使用GDB打断点调试，观察数据流动；或者从执行计划的选择入手，跟到优化器的最小代价选择函数。

理解数据库的前提是掌握计算机底层原理——从键盘输入数据到最终写入硬盘的完整路径。如果连这个基础都没有，即便有AI辅助也难以真正理解数据库内核。

AI显著降低了阅读和理解代码的门槛。PG所有讨论都公开在邮件列表中，可以把讨论链接丢给AI，快速了解某个改动的前因后果。

板块三：核心痛点——表膨胀与迁移实践

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

社区并非没有关注表膨胀问题——PG 17有增量优化，PG 19支持了原生的在线VACUUM FULL。但根本性解决方案（如64位事务ID）仍在讨论中，从2020年推到现在依然没有实质进展。

从运维角度，表膨胀可以通过监控、参数调优、定时任务等手段治理，不一定非要等内核彻底解决。

In-place update与out-of-place update是数据库诞生之初就存在的两条不同技术路线，没有绝对优劣。Oracle的UNDO机制发展了几十年才相对成熟，即便那样也仍有UNDO空间不释放的问题。

关于迁移，不应期望新数据库完全兼容旧数据库的行为，而应主动适应新数据库的特性。厂商也需要把文档写好，让AI能帮上开发者的忙。

板块四：如何参与社区与未来展望

中国开发者参与社区的两个主要障碍：一是不习惯用邮件列表沟通，二是不习惯用英文表达。这两个问题现在都可以借助AI解决——先写好中文再翻译发出去。

贡献可以从日常运维中的重复性工作入手，发现PG缺失的功能，在AI辅助下尝试实现，暂时不想提交社区可以先在内部使用或做成扩展。提Bug也是很好的切入点——生产中遇到的问题，借助AI在源码中验证后提交到社区。

国内厂商应把员工参与社区贡献纳入KPI，而不仅仅是靠个人情怀。

关于用Rust重写PG：底层软件对语言有特定要求，必须使用编译型语言。Rust的内存管理更好，但会带来额外的性能检查开销。况且用AI写了几百万行代码后，用哪种语言写的已经不重要了。

四、寄语

萧少聪：建议大家用AI手段去理解产品，但不要祈求AI帮你做所有设计，真正掌握知识必须自己干过。

杨向博：国内厂商应把员工参与社区贡献纳入KPI，而不仅仅是靠个人情怀，实打实回馈社区。

崔鹏：中国拥有全球最大的PG用户群和最活跃的AI开发群体，两者合流之时，就是中国开发者从参与者变成引领者之日。

吕海波：PG与操作系统、体系结构在深层次交汇。把深处知识关联起来的能力，目前还是人的优势。

周煦能：AI只是工具，最终责任还是人来。要追求对技术的理解比AI更深。