openGauss的SQL引擎在3.1.0版本中做了哪些优化?

openGauss3.1.0版本通过优化分区表页面估算、去除不必要的PartitionIterator算子和改进SeqScan算子,提升数据库执行性能,特别是针对分区表和CPU密集型场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

openGauss的SQL引擎在3.1.0版本中做了哪些优化?

收录于合集#技术干货83个

查询执行能力对数据库来说至关重要,这直接决定了查询语句生成的执行计划以何种方式进行执行,如果哪个执行算子的执行表现不好,将会对数据库的整体性能产生极大的影响。同时,执行算子的实现也极大考验一款数据库的工程实现能力。为此,openGauss数据库在3.1.0版本中,进一步优化了当前的部分执行算子,并希望通过优化执行算子的实现,来提高数据库的整体表现。下面介绍一下在该版本中,openGauss数据库都做了哪些SQL引擎的优化。

分区表页面估算优化

目前分区表的统计信息,代价模型使用的是普通表的机制,由于分区表和普通表结构上的不同,所以不能完全依赖普通表的机制去处理分区表的代价问题。由于分区表存在天然的分区优势,所以在分区剪枝的情况下,SQL语句在查询过程中不会访问所有分区。对于分区存在剪枝的场景,分区表页面统计时就不能单纯的统计所有分区的页面。在剪枝场景下只需要统计剪枝后的分区页面数即可。由于目前分区表没有统计每个分区的页面数,因此基于均匀性假设(分区页面不倾斜),用以下公式估算分区页面数:

剪枝后分区页面数 = 分区表总页面数 * (剪枝后分区数 / 总分区数)

通过改进分区表页面的估算方法,可以优化数据库的表扫描性能,从而提升数据库在分区表场景中的执行表现。该特性可通过GUC参数partition_page_estimation控制。

Partition Iterator算子优化

在openGauss数据库中,分区表是依靠分区迭代算子进行分区扫描的,迭代算子控制每一个分区依次扫描数据。当分区剪枝结果只有一个分区时,迭代算子已经失去了迭代器的作用,在此情况下消除迭代算子,可以避免执行时迭代算子计算的开销。由于执行器的pipeline架构,迭代算子会被重复执行,在数据量比较大的场景下消除迭代算子的收益将十分可观。故在该版本中,我们通过对迭代算子进行改进,消除分区扫描时的overhead,进而提升数据库在该场景下的执行性能。该特性可通过GUC参数partition_iterator_elimination控制。

SeqScan算子优化

开启该优化,当用户不采集cpu信息时(例如explain cpu off),关闭cpu信息采集功能(例如执行CPUUsageGetCurrent函数),从而减少cpu执行周期。该特性不影响正常的cpu信息采集,相关监控视图和系统函数不受影响。同时,从磁盘读取数据时,优化mdread机制,减少冗余的checksum检查,进而通过消除无用的操作来提升数据库性能。该特性可通过GUC参数enable_seqscan_fusion控制。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值