由PG分会发起的“PG ACE深度访谈”栏目，旨在挖掘PG ACE对数据库行业的深度洞察，分享他们对行业发展的思考和个人感悟，对广大PGer们具有实际借鉴意义。
以下正文，转载请注明出处，并获得吕海波老师及PG分会允许。
我没啥爱好，快50岁的人了，对很多事情渐渐失去了兴趣。现在是：“晚来无所好，唯爱数据库”。我的家乡到是可以说下，开封市，国家认定的第一批古都，素有“七朝古都”之称。开封市的主城区，至今仍在古城墙的环绕中，城墙外还有圈护城河。我家就在城墙不远处，以至于我小时候一直认为：“城市、城市，有城墙才能叫城市。”长大以后，去了其他城市，才发现都没有城墙，有城墙的是少数。
本来开封是七朝古都，还挺稀少的。但后来，这古都也和国产数据库一样，刷刷的冒出来。而且性能提升都不是以百分之多少算的，提升个几倍都不好意思跟人打招呼。古都也是，小时候大人们会掰着手指跟我们细讲“七朝”都是那七朝，现在不一样了，突然冒出一堆八朝、九朝。果然通货膨胀的不只有货币，还有古都和国产数据库。
另外，介绍一个我们老家方言：“刺溜”，类似象声词，形容很快，嗖的一下。这个词待会要用，我先提前介绍下。
个人公众号：IT知识刺客
大概从去年底，参加完PG生态大会后，开始写这个公众号。在10来年前，还搞Oracle的时候，我曾经很热心的做过一段时间的分享，还写了本书《Oracle内核技术揭密》。分享知识的同时，也是一个总结、吸收、消化的过程。我也一直比较乐于分享知识、传播知识。但是后来面临转型，实在没什么拿的出手的东西去分享，也就慢慢不再写东西了。直到去年，转型转的也差不多了，是时候重新开始总结、消化、吸收了。所以从去年就又开始动笔了。
我公众号上主要三类文章，历史故事、趋势分析和技术总结。
历史故事现在就两个系列，《卡脖子的数据库》、《数据库传奇 – 被忽略的历史》。
《卡脖子的数据库》主要突出一点，DBMS，数据库管理系统，是现代商业管理中的一环。DB不只是DB，后面还有个MS，Management System，“管理系统”。而如Oracle这样的数据库，是深深嵌入现代商业管理体系之中的，这是“国产替换”时，常被忽视的一点，它的影响，是深刻的。具体而言，都在《卡脖子的数据库》之中了。有兴趣可以去读读看，并不涉及很深的技术，老少咸宜。
《数据库传奇 – 被忽略的历史》，我觉得更为宏大，现在发布了四篇，主要讲两位数据库开创者巴赫曼和科德的故事。巴赫曼因为推出第一个数据库软件：IDS，而名留青史，被尊为数据库之父，他开创性的把数据库搞成了一种专门门类的软件。科德，则被称为关系型数据库之父，因为他提出了关系代数。而之所以叫“被忽略”的历史，是因为科德和巴赫曼在做出他们的创造性成果前，都有一段相似（但又有不同）的经历。
科德打工多年，临近40岁时，去考了研、读了博。在读完博之后不久，科德就“龙场悟道”，提出关系代数、关系模型。问题是，科德去读了什么专业、什么方向的博？你可以百度上查一下，还是能查到的，不少关于科德的资料都有讲：“科德感到自己硬件知识不足，去学习硬件。”
这是很多讲数据库故事众公号一笔带过的事，毕竟几十年前科德的选择，和我们有什么关系呢。而恰好，巴赫曼在推出第一个数据库软件IDS前，在陶氏化工负责一个硬件相关的项目。而且这个项目长达三年之久。搞了三年硬件后不久，巴赫曼就开始了他的封神之路：主持开发第一个数据库，IDS。先贤们都感到自己“硬件”知识不足，我们现在通常不会有这样的担心，因为操作系统、编译器，为我们隔离了硬件的复杂性。
但，真的是这样吗？如果要开发数据库这样的基础软件，真的不需要像科德、巴赫曼那样，去完善下自己的硬件知识吗？
在“IT知识刺客”中，有不少基于现代处理器体系结构（也就是硬件）的优化，比如这篇：《分布式数据库与i++/++i问题随想》。大学老师最爱问题：i++和++i的爱恨纠葛。站在应用层软件开发者的角度，i++与++i没有区别，但站在基础软件角度，它们并不相同，而且无论操作系统，还是编译器，都无法为基础软件做出最优抉择，这是考验你基础知识的时候，这或许能从一定程度上回答，为什么巴赫曼、科德，在补上了硬件知识的短板后，迅速开门立派、成为一代宗师。
其实“IT知识刺客”中，技术总结文章，和历史故事文章是相结合的。你读了技术总结文章，扩展了自己的知识边界，明白了自身不足，再去看先贤的历史故事，才能明白数据库如何发展到如今的样子，以后又将如何发展。
读过《数据库传奇 – 被忽略的历史》1至4的不要急，我一直在抽空写第5篇。可以先做个内容预告，做为数据库早期的两位创始者，巴赫曼和科德曾有过激烈的交锋，但从成就上而论，科德的关系模型无疑是超过了巴赫曼的。关系模型到底伟大在何处？
我很想用《三体2：黑暗森林》开篇的一段来讲讲这个问题。
《黑暗森林》开篇，是叶文洁在启发罗辑，让罗辑创立“宇宙社会学”。像欧氏几何一样，设定几条不证自明的公理，过两点只有一条直线、两点的平行线只有一条等等，然后在这几条简单的公理基础上，演化成宏大的欧氏几何。
科德的关系代数也类似。他首先定义了一个基本名词：关系（简单点说，就是行与列的集合）。然后基于关系再总结三种基本运算：选择、投影、连接。仅此而已，欧氏几何还有5条公理。关系代数比欧氏几何还要简洁。大道至简吗。
科德证明了，无论多复杂的数据检索需求，都可以在“关系”上，以选择、投影、连接三种基本运算为基础实现。当然，这个“实现”的过程，可不能乱来，无规矩不成方圆。科德又进一步证明了选择、投影、连接遵循“交换律”、“结合律”、“分配律”，等基本定律。在实现复杂数据检索需求时，要用已证明的基本定律来进行。
比如一个简单的查询条件：a.id = b.id and a.id=10。
对表b，不必选择表b的每一行与表a中满足id等于10的行进行关联，因为通过“交换律”、“结合律”、“分配律”，上面的条件可以推导出：a.id = b.id and a.id=10 and b.id=10。
从a.id = b.id and a.id=10，推导出b.id=10的过程，不能靠直觉，需要有证明过程。因为简单的条件可以靠直觉，十分复杂的查询需求，还靠直觉，出错的概率几乎是百分百的。
关系，选择/投影/连接，再加上交换律、结合律等基本定律，这就是关系代数。
关系，相当于数字。
选择/投影/连接，相当于加、减、乘、除四则运算。
交换律、结合律、分配律等定律，四则运算中也有这些。
四则运算演化成复杂的代数。科德的理论，也最终演化而成：关系代数。它应该是离散数学、集合论的一个子集。
我不严谨点说，可以先执行a.id=10 and b.id=10，这是由于关系代数也遵循“交换律”与“结合律”。你随便写个Python脚本，它里面的每条命令并不遵循“交换律”与“结合律”，Python并不能随便交换两条命令的执行顺序。这都是关系代数已经为我们证明过的结论。
做为数学的一个分枝，关系代数十分宏大，而且能实际的应用于各种数据检索、查询。想了解数学是如何实际应用于现实世界的，可以仔细读读关系代数的论文。但这并不是科德唯一的贡献。
数学之中，从来不缺奇思妙想，而关系代数还有一个难能可贵之处，就是它是可实现的。关系代数的抽象级别很高，以至于在刚诞生时，非常多的人认为以当时计算机的算力水平，无法将关系代数应用于数据库。但科德的硬件相关专业博士不是白读的，他坚信关系代数可以实现。你让一个不了解计算机的纯数学家去设计算法，他设计的算法可能很好，但很有可能无法在当下的计算机上实现。
科德在创建关系代数理论时，就充分考虑了计算机的体系结构，可以说关系代数是和计算机结合最密切的数学理论之一。唯一遗憾的时，科德出身于牛津大学数学专业，他用极其严谨的数学符号推广他的数据库理念，甚至将其命名为关系代数。与之相比，巴赫曼的网状模型数据库，并不能称为网状代数。
而当时大多数IT从业者，并不具备科德这种专业数学家的素养。相比数学，当时的IT人士更偏向物理。因此科德各种用古怪拉丁符号描述的关系代数，对很多人来说，就像崂山道士的符箓，“太上老君急急如律令”什么的。这影响了关系代数的传播，直到其他几位大师加入，比如SQL语言的发明者钱伯林等。
这些故事细读下来，挺有用的。它生动的为我们展示了处理器体系结构、数学，是如何相遇，碰撞而成数据库。如今新的理论层出不穷，比如LSM Tree，它的基础是Key-Value，用KV来实现行与列。因此从本质上，LSM Tree仍符合关系代数，它是关系模型大家庭的一员。它只不过是“关系”这种数据组织形式的一种存储方式，它的这种存储方式对磁盘更加友好。
了解这些，你不容易被别有用心的人忽悠，什么LSMTree比传统关系型要先进，LSMTree也是关系型。相比用堆表、IOT（索引组织表）来存储“关系”，LSMTree有优势也有劣势。只有长处没有短处的都是骗子，这是千古不破的真理。
好了，关于我写公众号的目的，我说的够多了，IT知识刺客，有兴趣去看看吧。
最近读过的，《快速掌握PostgreSQL版本新特性》，纵览了PG各个版本的特性。挺不错的，推荐阅读。
还有一本书是最近“精读”的，现在也常常翻看：《超标量处理器设计》。说到处理器（也就是CPU），大多数人还是觉得7纳米啊、4纳米啊、集成度快要达到物理限制了等等。
我们的感觉，CPU就是一个黑盒子，我把指令给它，它刺溜一下，执行完了。对，刺溜这词就用在这儿了。就是想形容CPU很快。
但实际上，一条指令，从进入CPU，到执行完毕，可不是刺溜一下。CPU内部有着非常多的模块，指令会不断在各种模块间穿梭，才能执行完成。应该说是刺溜、刺溜、刺溜、……刺溜好多下，一条指令才能执行完成。
这和《超标量处理器设计》这本书有什么关系呢？
简单点说，读读这本书，才能了解指令到底"刺溜"了几下，才完成了整个执行过程。不过，这又有啥意义呢？我完全可以把CPU当黑盒子啊，我把指令给它，它来执行。就像数据库，对于应用开发者来说，把数据库当黑盒子没问题，你给数据库SQL，数据库给你结果。
如果你的程序使用了数据库的话，如果你能适当打开数据库这个黑盒子，你能写出更好的应用程序、更好的SQL。我觉得这就是读《超标量处理器设计》的意义。
其实我接触PG的时间并不长，我是在2020年开始研究PG源码的，之前对PG并无了解。可以说，我是很年轻的PGer。
不过，要说我跟数据库的缘分，可就长了，我是2003年开始从事Oracle相关工作的。从那时候算，进入数据库领域，至今已经21年了。
如果要算上使用Foxpro的时间，还可以往前提个6、7年。我写的第一个商用基于“数据库”的应用软件，是1997年用Foxpro写的。不过，把Foxpro也算数据库，稍稍有点争议。再说，简历中写21年数据库相关工作经验，已经够久了。也不用再增加个6、7年了。
另外，我搞MySQL的时间也挺久的了。2009年，当时在阿里巴巴做DBA。插句题外话，当时我的职级已经是P8，这在十来年前，是非常高的职级了。那时候阿里启动了去IOE，我也因此开始接触MySQL，算下来，到现在也搞MySQL也十几年了。
那为什么我最终选择了PostgreSQL呢？！
所有的OLTP数据库中，Oracle无疑是最强的。但是，Oracle DBA的上限并不是很高。对于热爱技术的人来说，你看到一些明显不合理的地方，却无能为力，也挺苦恼的。
都说Oracle的代码是屎山，你见过这屎山那怕一粒屎吗？我知道Oracle并不开源，但，想的话，还是能见见这屎山中一粒屎的。
我在知乎上回答过一个问题：“C++无锁(lock free)数据结构与有锁数据结构相比，速度，性能等有何区别?多线程中如何选择？”。我的知乎IT是texttime vage，可以去搜一下看看我的回答，在文章的最后，我展示了屎山中的一粒屎。
虽然我知道，它是一粒屎，但是，这又能怎么样呢。不过，这的确有点不甘心，要知道发现这粒屎的难度，远远超过修复它，特别是在没有源码的情况下。
花了这么大功夫发现了它，但又拿它没有办法。看不惯又干不掉的这种感觉，虽然在我们生活中处处都存在，但还是不爽。更何况大概在5、6年前，2018、2019年前后吧，我申请过Oracle ACE。
做为一名曾在三家世界级互联网巨头从事数据库工作，维护过这个世界上最大、最繁忙Oracle数据库之一，且分享过大量Oracle技术章，出版过Oracle技术书籍，讲授过多期OCM培训课程、且09年就已经是阿里P8、有着17年Oracle DBA经验的DBA来说，我的Oracle ACE申请，不出意外的一定会通过。
但不出意外是不可能的。Oracle给我回了封邮件，大意是：“你是一个好人，但我们不适合。”当然，在2018、19年前后，我搞MySQL更多一些，不过，给我一个MySQL ACE也可以啊。搞了10年MySQL，当时我觉得也够格的。
之后不久，我就转投PostgreSQL阵营了。再然后，时间不长，PG分会就授于我PG ACE。后面更是授给我PG ACED。也算弥补了我的遗憾。
当然，我转投PG，并不是因为ACE。做为一个搞了20年数据库的人来说，写一个数据库，是我的理想。我一个人能力有限，从头写，没有必要。如果要基于一款开源数据库，PG是不二选择。我之所以这样认为，并不是单纯因为PG开源协议更开放，而是从技术角度分析。
我在去年（2023年）PG生态大会上，分享过对MySQL、PG从处理器角度的对比分析。我选择MySQL、PG中完成相类似功能的程序段，做为分析目标。分析目标要尽量的短、小。因为太长的程序段，很多指标会被平均化，难以发现问题。
我放在PPT中当例子的，有两段程序，其一是DML事务开始时，获得事务ID（PG中是XID）的过程。这段程序的逻辑，在MySQL、PG中几乎是完全一样的。程序段长度只有几十行，MySQL完成这段逻辑，使用了1137条指令（汇编指令），PG使用了1251条指令。
指令数1千出头，已经是非常短小的观察目标了，这样很多指标不会被平均化。观察的结果，MySQL在获得事务ID时，使用了1137条指令，进行了291次内存读，249次内存写，总计使用了12017个时钟周期。我这里的时间单位都使用CPU自身的时钟周期，这个单位的精度足够高。如果你是3GHz的CPU，那就是3个时钟周期1纳秒，每个时钟周期0.333…纳秒。
PG呢，相同的逻辑，使用了1251条指令，进行了316次内存读，262次内存写。指令数、内存读与写的次数，PG都高于MySQL，在完成相同逻辑情况下，PG程序的复杂度更高一些。但最终PG使用了9096个时钟周期。
PG用了更多的指令，进行了更多的内存读、写，但使用的时钟周期却更少，原因何在？
进一步的分析，发现MySQL的TLB Miss非常高。平均下来，MySQL每条指令对应的TLB Load Miss，为2.52，TLB Store Miss为0.5；而PG每条指令对应的TLB Load Miss只有1.05，TLB Store Miss仅为0.17。
更高TLB Miss使读写内存时的停顿更高，平均来说，MySQL每条指令对应5.38个时钟周期的访存停顿。而PG每条指令对应3.11个时钟周期的停顿。
如果你并不了解TLB Miss的意义，也无妨，我们打个比方，你开一辆MySQL牌子的汽车，在每个红绿灯路口，平均等待5.38分钟。换成PG牌汽车，平均每个路口等待3.11分钟。
除了获得事务ID或XID的过程，PPT中还举了一个例子，在缓存中（Buffer Pool或Shared Buffer）定位索引root块，这包括：
1) 计算HASH值
2) 搜索HASH表
3) 得到块地址
一共三大步骤。通过观察分析，也得到了相似结果。
PPT中也给出了最终的分析结果：
“PG的胜出，在于语言。C++的体系，使代码往往分布在相对更广、更扩散的地址空间，因此导致TLB Miss较高。对时间特别敏感的领域，相比C++/Rust，C语言仍有不可替代的优势。但数据库在大多数情况下对时间的敏感度没那么高，因此MySQL虽然使用C++，但凭借更加的简单易用，仍能得到大范围的使用。”
从处理器角度分析，PG胜出，是胜在语言。同样都是高水平开发者写的程序，C语言程序简单，编译器更加容易控制编译过程，产生的结果效率更高。当然，C语言更难控制，单是一个“指针”，就能把人搞晕。所以这里加了一句话：“同样都是高水平开发者写的程序”。
PG，是有影响力的开源数据库中，唯一全部使用C语言的。以PG为基础做自己的数据库，起码不会在“起点”上就输给如Oracle这样的数据库。这是我在搞了十几年Oracle、近十年MySQL后，转型到PG阵营的最主要原因。
如果对这段分析有兴趣，在去年PG生态大会上，我的演讲题目是《跳出数据库，回看数据库 ---- 谈数据库技术的微创新》，完整的PPT下载、和相关视频，可以在PG分会公众号：“开源软件联盟PostgreSQL分会“中获取。也可以在我的公众号：“IT知识刺客”中搜索“PG生态大会视频”。
我学生时代专业是会计，那是1993年到1996年，我读的是职业高中，类似蓝翔挖掘机专修学校、新东方厨师学校这种。毕业时，我考了珠算能手一级证书，至今，我的速算能力是远超其他人的。
要说学校学的东西是否帮助了现在的工作，我们在学校还学了dBase，但学的很简单，老师说这是数据库，但是不是关系型，没说。估计老师自己都不知道啥是关系型数据库。
哦，对，有一样在学校学的东西，我现在每天都在用：五笔字型。我是我们班打字比赛第二名，巅峰时每分钟能打120个汉字。按每个汉字平均击键3次，每分钟要击键360次，每秒6次。在~嘀~嗒之间，我能完成6次击键动作。还挺了不起的。
但这并不能为我换来一份工作。IT怎么也算技术性行业，对于没有学历的人来说，搞IT还挺难的。但我看有人分析的还挺有道理，人的价值，在一定程度上取决于生产资料的昂贵程度。依赖昂贵的生产资料，人的价值就相应缩小。
如果一种大型机器设备的操作员，这种大型设备很昂贵，操作员的价值就没那大。电脑，特别是软件从业人员，生产资料就是一台电脑，几千块足够。因此相对其他行业，在软件行业，人的价值更加被重视。
当然，这个结论并不是放之四海皆准。但，软件行业在过去的几十年里，机会还是有的。包括阿里、ebay这样的国际化公司，还是有一定的包容性的。特别是ebay这样本来就是跨国企业，对学历、英语的要求都极高，我们当年的同事中，不乏有出身斯坦福大学的名校生，一些印度裔同事，也有出身印度名校的（不确定是否是三傻大闹宝莱坞的印度理工，据说是），但并没有拒绝我这个英语交流障碍的职高生。所以说，软件行业，机会还是有的。
我在做一个PG Shared Pool项目。
PG各进程间共享内存，除了Shared Buffer外，并不多。也因此共享内存的管理也比较分散，没有一个集中管理的共享内存池。这带来一个问题，比如我需要增加一个功能，这个功能需要一块共享内存，那就在数据库启动时，多分配一块共享内存给我用。
如果以后需要经常性的增加功能、去除以前增加的功能、修改功能扩大或减少内存需求，……，那就需要频繁的调整共享内存的分配数额。而且，分配出去的共享内存，完全由使用者管理，没有统一的管理接口。比如LRU、Freelists等内存池基本功能，需要自行提供，共享内存管理没有这些功能。
也就是说，共享内存在PG中并不是集中管理的。PG的内存上下文，memory context，有完善的内存池管理功能，Freelists等都有，而且以树状结构提供内存块的管理。但它是针对Session私有内存。
相比之下，Oracle有一个集中管理的共享内存池：共享池。对Oracle来说，功能的迭代不需要考虑内存问题，需要共享内存，就去共享池中申请就行了。共享池有Freelists、LRU、HASH、堆与n层子堆的层次关系等，完整的通用功能。
比如，Oracle在10G、11G中，添加了一个IMU功能，In Memory Undo。它可以把事务中多条DML SQL的Redo（相当于PG的xlog），缓存在共享内存中，在提交时一次性写入Log Buffer(相当于WAL Buffer)。
这个功能可以减少Log Buffer的写次数。因为每写一次Log Buffer，都需要持有相关的锁，减少写次数，也就是减少了锁的争用。
Oracle中Log Buffer锁最重要的是Redo Allocation Latch，还有不太会成为问题的Redo Writing Latch。它们相当于PG中的WAL Insert Pos锁和WAL Insert锁。
可以认为，这个IMU功能，就是用于减少WAL Insert Pos、WAL Insert锁竞争的。
这块针对IMU，缓存未提交事务Redo数据的缓存，必须在公共缓存池中，否则，就是从一定程度上偏离了Write Ahead Log。
因为一条DML SQL已经完成，新的数据已经写到Shared Buffer，块已经变脏，所有Session都能读到。但它对应的Redo数据，需要在写Shared Buffer前已经写入内存，但是在Session私有内存，并不是所有Session都能读到。
这种情况也不能说违反了WAL，但我用“偏离”两个字，是没问题。正是为了不偏离WAL规则，Oracle把“缓存未提交事务Redo数据的缓存”，也放在共享内存中。
这块内存的管理是十分复杂的，它的大小要可调，要有重用机制、要避免碎片，等等。对Oracle来说，这都不成问题，共享池，Shared Pool，本来就是干这个的，IMU模块只需要去共享池中申请一块内存就可以了，随着并发的增长，还可以扩展大小，并发降低时，还可以把多余空间还回共享池，这是共享池本身提供的功能。
要实现一个IMU功能，如果要先实现一个共享内存池管理模块，而且是高并发版的共享内存池管理，这个功能的复杂度其实远超IMU。如果没有现成的共享池，算了算了，IMU还是不要去想了。
数据库很多功能都需要一块共享内存，没有一个高并发、高质量的共享内存池，很多功能都只能算了吧。
而Oracle对内核的改动，就会方便很多。IMU、多Log Buffer、多LGWR……，甚至像ASM，这种基石般的模块，没有共享池，实现难度也将大大增加。ASM有非常多的元数据，缓存在共享池中的数据字典缓存中，使用数据字典缓存统一的算法管理。
你如果要为PG增加个ASM试试。你还是要先实现一个高并发的、大小可调、有重用机制、避免碎片……等等功能的共享内存池，然后再来实现ASM。
一个大型、高并发的系统软件，想要走的更远，有一块集中管理的共享内存池，由内存池提供统一的Freelist、LRU、HASH等基础功能，这是必由之路。
那么，实现了PG共享池后，要先把什么数据缓存其中呢？我的第一步计划是，先缓存SQL Plan。
PG把Plan缓存在Session私有内存中。Plan在公共内存还是在私有内存都可以，这不是问题，问题是就算是使用了Cache 的Plan，PG中的成本也是挺高的。
Oracle 如果Cache Plan命中，可以做到几乎无代价的得到Plan，开始执行Plan。但PG的Cache Plan命中，只是代价减少，离几乎无代价，还相差很远。
主要是因为Plan缓存在私有内存中，要考虑内存空间占用问题。如果Plan和相关数据占10KB字节，有1000个Session缓存，那就是10KB * 1000，差不多10MB字节。如果Sessoin中缓存了几百条SQL的Plan呢？那就是几个G内存了。如果缓存的Plan更多呢？如果SQL Plan占内存更大呢？……
所以，Plan缓存在私有空间，那就要尽量减少Plan数量、减少每个Plan占用空间。牺牲时间，换空间。要不随着数据库并发的提高，内存会被撑爆的。
如果Plan在公共空间，则不存在这样的问题。Plan的主要数据只在公共空间缓存一份，Session私有空间只记录一些指针、状态即可。
在不需要考虑时间换空间的情况下，可以尽可能多的缓存各种数据，最终达到，让命中Cache Plan的成本，接近于0（获得Plan的成本当然不可能是0，还要有搜索Plan的成本）。
这是实现PG版共享池后的第一步计划，之后，ASM，甚至RAC，都可以考虑。像RAC，Cache Fusion的前提是要有一个分布式锁管理，大量的RAC相关分布式锁放那儿呢，当然是共享池啊。有一块高效的共享内存池，RAC已经完成了一小半功能。
怎么实现这个高效、高质量的共享内存池呢？
虽然市面上的内存池实现有不少，但都不是针对数据库场景，或者不是针对OLTP数据库的。有一个共享内存池算法，是针对数据库，而且是针对OLTP数据库的。并且在世界无数大型企业使用过，几十年发展、踩坑无数，而且支持Cache Plan、ASM、RAC各种功能。
你们应该猜到名字了，对，它就是Oracle。
但Oracle不开源啊，它的共享池算法，也不会告诉你。没关系，世界上有一种技术，叫逆向。
为了能让PG Shared Pool站在巨人的肩膀上，我对Oracle的共享池、各种类型软/硬解析，进行了逆向。单是逆向的文档，都整理了两万多字，在Word中有61页之多。这个项目的第一版，应该会在7月份前后完成，到时候再跟大家做进一步的分享。
当然，并不是Oracle有什么，PG就要有。
我曾经在PG分会组织的PG Conf大会上，和国际社区的开发者有过短暂的交流，但可能是我说话的方式不太好，我常说：“Oracle中这种方式不错，PG也可以尝试一下……”。
我的感觉是，国际社区的开发者们，对这种说话的方式还挺排斥的。以至于有人曾说：“为什么Oracle怎么做，PG就也要怎么做。”
我并不认为Oracle所有地方都好，像Oracle的Cache Buffer Chain Latch机制（简称CBC Latch），直到现在了，都没有分成共享、独占两种模式，只有独占一种方式。所以CBC Latch的数量就要非常的多。
CBC Latch和PG中的Hash Partition Mapping Lock功能相同，这种锁在PG只有128个，Oracle数量可调，从几万到几百万不等，取决于Buffer Cache大小。
CBC Latch只要也像PG，改成共享、独占两种模式，能大大减少竞争。
当然是64位XID。
别看只改一个变量的长度，但涉及相关代码非常多，改动量或许不多，但考虑各种相关代码千丝万缕的联系，复杂度极高。而且，32位的XID虽说问题也不是太大，但对使用者的要求比较高。还是非常希望XID能变为64位。
对于UNDO，我到并不是很期望PG学习Oracle的UNDO模式。
UNDO有UNDO的问题，但总的来说，UNDO的确更简单、更易于管理。但无UNDO时，Insert代价更低，对于高并发的Insert，使用HASH表分散向同一块中插入数据的竞争，可以有更高的并发。这十分有利用现在的时序数据库。因为时序数据库就是Insert多，其他SQL少。
Linux下，vim + scope。
Window下，vscode。
代码在Linux下，需要大段的查看、编辑那个文件，我把它拷贝到Windows下，用vscode查看、编辑。
另外，gdb，也是我最常用的工具。
我自己还写了一个“谛听”工具，西游记中那个能听到所有声音的神仙。曾经听六耳猕猴和真正孙悟空真假的那个。“谛听”使用CPU中的硬件断点，中断目标程序的执行，激活CPU中的硬件性能资料收集器（也就是CPU中一组寄存器）。总之就是一点，使用CPU本身的硬件功能，对目标程序段进行画象。
我在去年PG生态大会《跳出数据库，回看数据库 ---- 谈数据库技术的微创新》的演讲中，介绍了“谛听”的实现原理。前面所说的MySQL和PG在处理器层面的对比，就是使用“谛听”得到的。
“谛听”的代码一共只有几十行，写这么个工具是很简单的事，所以我也没开源。相关原理在PG生态大会中都做了介绍。
“谛听”是基于处理器知识的，包括“画像”的结果分析，都是面向处理器的。要熟悉处理器原理，这会比较难。比写“谛听”几十行程序要难多了。
但是，别人都不会的东西，不正是我们的机会吗，是吧。对“谛听”感兴趣的去看PG生态大会的视频吧。
从事运维的话，门槛并不算很高。除去PG的运维技能，还有Linux的基础操作，怎么看CPU使用率、I/O使用率、内存使用情况等等，也是必备常识。
如果从事数据库周边开发，也还好。PG的插件开发，对数据库内核要求并不高，可以很好的利用插件，实现一些扩展功能。比如有人搞了pg4ml，这里面对ml的要求，会比pg更高。
如果从事数据库内核开发，要求就很高。数据库毕竟是基础软件，除去深厚的开发功底外，数据库之下的OS、处理器，都要有相当程度的积累才行。
《PG生态大会》和《PG Conf Asia》，这都是开源软件联盟PostgreSQL分会主办的，氛围挺好，通常我都会安排时间年年参与。我的一些研究方向，也会在大会上做分享。比如去年PG生态大会中讲述的“谛听”原理与MySQL/PG比较问题，等等。
另外，数据库大会，DTCC，我基本也是年年参加，也会在大会上分享我在技术方面的研究成果。
探索，与分享。
做为PG ACED，我一直非常重视分享。其实写技术文章、演讲，还有讲课，都是对过往技术的总结，我坚持分享已经很久了。
但没东西可分享时，我也会慢慢去探索。从Oracle转型到其他数据库时，我探索了好长时间。前几年，从2020年底、2021年初开始，我又花了几年时间，探索处理器内部的秘密。没东西可说时，就“退而结网”，结成网了，再通过分享，总结自己所学，也能让更多人知道你默默探索的结果。
开源软件联盟PostgreSQL分会，是一个很好的分享平台。甚至对源码有兴趣的话，还可以参与IvorySQL社区。我每年都会花大量的时间，参于开源软件联盟PostgreSQL分会组织的“北京大学PG内核课程”的讲授。
这是北大硕士阶段正式课程，要占学分的，可不是普通培训。讲一个学期，还是挺占时间的。但每次课程，都是对我自己知识的总结、提高。所以每年我都会留出大量时间，参与课程讲授，分享的同时，也巩固自己的知识体系。
说说数据库开发的纯自研与基于开源吧。
现在基于开源，基本就是基于PG。PG的代码质量，放眼整个世界范围，也能说首屈一指。你基于PG，添加自己想做的东西，你就站在了巨人的肩膀上。其优势，比从头到尾纯自研一个数据库，不可同日而语。
至于代码的掌握与可控程度，纯自研也并不比基于PG好到哪儿去。如果是纯自研团队，随着人材的自然流动，离开人遗留的代码会越来越多，这些代码的可读性，会比PG代码的可读性更好吗？绝对不会。一个纯自研数据库，自研团队对代码的掌握程度，并不会比基于PG的团队更强。
无论从那一点上说来，纯自研相比基于PG，都并无优势。
如果你有什么好的想法，开始行动吧，基于PG添加功能模块，参于PG国际社区、ivorySQL社区等各种PG社区，成为贡献者，在开源社区中分享知识，让自己的职业生涯，更上一层楼。
