如上图，粉色的部分就是openGauss界定的内核部分，包括线程管理、通信管理、SQL引擎、存储引擎、安全管理、AI。那么，openGauss在内核上都有哪些创新？其实，上图已经能看出一部分东西。
众所周之，openGauss内核早期衍生自PostgreSQL-XC，但如今，openGauss与PostgreSQL-在架构和内核上，已经有了极大的差异。
如上图，openGauss执行模型，采用线程池模型。而PostgreSQL是进程模型。这么改有什么好处？进程模型，数据库进程通过共享内存实现通讯和数据共享，每个进程对应一个并发连接，这就存在高并发下，进程切换性能损耗，导致多核扩展性问题。而线程池技术的整体设计思想是线程资源池化、并且在不同连接之间复用，因此，高并发连接切换代价小，内存损耗小，执行效率高。
李国良说，openGauss尤其在核心的优化器、执行器、存储引擎方面，做了很多的改进和优化，与传统的关系型数据库，有了本质区别。
存储引擎方面，openGauss实现存储引擎融合，即一套架构支持多种存储模式。openGauss支持多引擎（行存储引擎、列存储引擎、内存引擎），而PostgreSQL仅支持行存储引擎。看起来只是多支持了2个引擎，但其中涉及很多关键技术。比如：openGauss行存储引擎采用原地更新(in-place update)设计（又名：Ustore存储引擎），追加写引擎（HEAP），支持MVCC（Multi-Version Concurrency Control，多版本并发控制），同时支持本地存储和存储、计算分离部署方式。
原地更新相比非原地更新有什么好处？李国良给老鱼打了个比方，简单的说，非原地更新是一张表一直往上加，有删有增，维护这张表代价非常大。openGauss 内核此前的版本使用的行存储引擎是Append Update（追加更新）模式，追加更新对于业务中的增、删以及HOT(Heap Only Tuple) Update(即同一页面内更新)有很好的表现，但对于跨数据页面的非HOT UPDATE场景，垃圾回收不够高效，因此，Ustore存储引擎应运而生。
众所周知，优化器的好坏会直接决定关系型数据库的强弱，优化器一般分为RBO（Rule-Based Optimizer）基于规则的优化器和CBO(Cost-Based Optimizer)基于代价的优化器，PostgreSQL支持CBO，openGauss支持CBO，SQL by pass。
虽然都支持CBO，但对复杂场景的优化能力是完全不同的。李国良说，openGauss在优化器的CBO上做了很多技术创新。首先，openGauss添加了很多查询重写规则，查询重写优化；其次，openGauss做了很多CBO代价的调优模型，适应不同场景；后，openGauss加了基于机器学习的代价估计方法和优化算法，使得优化器更智能，适用于更多、更全面的复杂场景。
Sql-bypass是openGauss针对OLTP场景开发的一个轻量化执行器，它解决的是什么问题？在典型的OLTP场景中，简单SQL查询占了很大部分比例。试想一下，如果一个简单的SQL查询因为复杂的CBO逻辑，而消耗不必要的CPU资源浪费执行时间，那肯定是不行的。SQL by pass就是为了加速这类查询设计的，可以极大地缩短执行器通用框架处理逻辑，极大地提升执行的性能。
执行器方面，为了提高SQL的执行速度，解决传统数据处理引擎条件逻辑冗余的问题，openGauss执行器引入了自适应实时编译（Codegen）技术，其核心思想是为具体的查询生成定制化的机器码代替通用的函数实现，并尽可能地将数据存储在CPU寄存器中。
总的来说，openGauss内核创新围绕“四高”原则，即：高性能、高可用、高安全、高智能。比如：高性能，openGauss聚焦了很多新型技术，包括NUMA-Aware技术、智能优化技术、内核并行执行的技术，这些都是在内核创新方面引领的一些新型技术。
高智能，在数据库内核方面涉及到很多优化技术，包括很多优化NP问题，以及代价估算技术。传统方式都是基于一些独立性假设、均匀分布假设，这导致估算结果非常不准确，而openGauss通过众多智能技术（智能索引技术、智能数据化分析技术、智能优化内核技术）提升准确性、提升数据库内核优化效率，提高可复制性。
