openGauss的SQL引擎在3.1.0版本中做了哪些优化？
查询执行能力对数据库来说至关重要，这直接决定了查询语句生成的执行计划以何种方式进行执行，如果哪个执行算子的执行表现不好，将会对数据库的整体性能产生极大的影响。同时，执行算子的实现也极大考验一款数据库的工程实现能力。为此，openGauss数据库在3.1.0版本中，进一步优化了当前的部分执行算子，并希望通过优化执行算子的实现，来提高数据库的整体表现。下面介绍一下在该版本中，openGauss数据库都做了哪些SQL引擎的优化。分区表页面估算优化目前分区表的统计信息，代价模型使用的是普通表的机制，由于分区表和普通表结构上的不同，所以不能完全依赖普通表的机制去处理分区表的代价问题。由于分区表存在天然的分区优势，所以在分区剪枝的情况下，SQL语句在查询过程中不会访问所有分区。对于分区存在剪枝的场景，分区表页面统计时就不能单纯的统计所有分区的页面。在剪枝场景下只需要统计剪枝后的分区页面数即可。由于目前分区表没有统计每个分区的页面数，因此基于均匀性假设（分区页面不倾斜），用以下公式估算分区页面数：剪枝后分区页面数=分区表总页面数*（剪枝后分区数/总分区数）通过改进分区表页面的估算方法，可以优化数据库的表扫描性能，从而提升数据库在分区表场景中的执行表现。该特性可通过GUC参数partition_page_estimation控制。PartitionIterator算子优化在openGauss数据库中，分区表是依靠分区迭代算子进行分区扫描的，迭代算子控制每一个分区依次扫描数据。当分区剪枝结果只有一个分区时，迭代算子已经失去了迭代器的作用，在此情况下消除迭代算子，可以避免执行时迭代算子计算的开销。由于执行器的pipeline架构，迭代算子会被重复执行，在数据量比较大的场景下消除迭代算子的收益将十分可观。故在该版本中，我们通过对迭代算子进行改进，消除分区扫描时的overhead，进而提升数据库在该场景下的执行性能。该特性可通过GUC参数partition_iterator_elimination控制。SeqScan算子优化开启该优化，当用户不采集cpu信息时(例如explaincpuoff)，关闭cpu信息采集功能（例如执行CPUUsageGetCurrent函数），从而减少cpu执行周期。该特性不影响正常的cpu信息采集，相关监控视图和系统函数不受影响。同时，从磁盘读取数据时，优化mdread机制，减少冗余的checksum检查，进而通过消除无用的操作来提升数据库性能。该特性可通过GUC参数enable_seqscan_fusion控制。上面的三个方面是该版本对openGauss数据库的SQL引擎的优化，后续我们还会对更多的openGauss数据库内部执行逻辑进行优化，敬请关注。
你可能想看：