想撼动Oracle，PG系国产你还不配！吐槽你连最基本的空间分配都没做好

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

第28期吐槽:PG 每次只扩展1个block

这个问题可能即将得到解决: 《PostgreSQL 16 preview - extend relation 优化, 扩展数据文件大幅度优化, 提升批量、高并发写入场景性能》

1、产品的问题点

• PG 每次只扩展1个block

2、问题点背后涉及的技术原理

• 当写入或更新数据时, 如果现有的数据文件无法放下新的tuple, 需要extend 数据文件, 但是PG只扩展1个数据块.

3、这个问题将影响哪些行业以及业务场景

• 高速写入的业务场景, 例如IOT, 时序, feedlog类.

4、会导致什么问题?

• 导致extend block exclusive锁竞争, 影响写入性能. PG 最近的很多个版本都在做写入优化, 其中也包含了extend block这块.

• 由于每次扩展1个数据块, 对应的数据文件大小也会频繁发生变化, 而PG使用的是文件系统来存储数据文件, 意味着inode也会发生变化, 文件系统inode变更也会带来的一些锁竞争问题.

5、业务上应该如何避免这个坑

• 编译时, 选择更大的block size, 只能弱化无法避免这个问题.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理更加复杂, 而且无法完全避免.

• 由于目前PG的一个实例只能选择一种block size规格, 如果选择大的block size, 会导致某些需要小block size的表可能性能变差并浪费更多shared buffer. (例如偏TP的业务)

7、数据库未来产品迭代如何修复这个坑

• 希望可以自定义扩展规则, 例如

• 表级别可以设置, 每次扩展多少个block, 或者:

• 根据数据表的大小, 阶梯性增加每次扩展多少个blocks, 直到封顶max extend blocks。业界领袖Oracle就是这么干的，不愧是领袖。

从近期的吐槽系列来观察, 即使是目前最先进的开源数据库PG离企业级标杆Oracle还有非常大距离, 虽然这一点不妨碍大量基于PG的国产数据库前赴后继的干O, 但如果你只是拿PG来改个名的话貌似还不配干O! 

国产厂商看到我下面吐槽的这些坑会不会后悔选择基于PG来造呢?  :

本期彩蛋-招商中,有需要的小伙伴可联系嵌入...

文章中的参考文档请点击阅读原文获得. 

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: