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

关注

原创 2026-08-13 17:30:06 196 阅读 AI 写同款· GEO 优化 ›

PostgreSQL技术内核与中国数据库创新路径深度解析在数据库技术领域，一个持续了近三十年的开源项目——PostgreSQL（简称PG），正深刻影响着全球乃至中国的技术格局。每当国内数据库厂商发布新产品，“基于PostgreSQL”或“兼容PostgreSQL”常常成为其技术标签。这不禁引发业界和开发者的广泛讨论：这是站在巨人肩膀上的高效创新，还是缺乏核心技术的“套壳”行为？中国数据库产业在经历了数十年的追赶与学习后，如今究竟走到了哪一步？本文将深入探讨PostgreSQL的技术内核、其在中国的发展生态，并尝试厘清“借鉴”与“创新”的边界，为开发者理解当下数据阅读详情

一、活动概况

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能帮上开发者的忙。