PBE
prepareStatement,将查询计划保存好,之后便可省去计划生成这一环节,其中保存的计划可以是存在参数的,后续执行时,只需要将参数绑定到计划上。
通常使用在OLTP场景,因为OLTP场景下的SQL,其计划生成环节在整个时间中的比例较大,且计划相对简单单一,因此将这部分提取出来,能获得很好的效果。
另外openGauss内存在全局计划缓存(GlobalPlanCache)的特性,这个特性并不会提升性能,主要是为了节省内存。
关于PBE的更多信息可看这篇 PBE协议
Bypass(OpFusion)
opfusion是openGauss独有的一个特性,可以理解成一个“简易执行器”,由会话级别参数enable_opfusion
控制开启关闭,用来高性能的执行简单SQL。
在计划生成完成之后,进入Executor流程执行之前,会先对计划进行检查,若检查通过,则会进行拦截,转而由opfusion进行执行,因此也叫Bypass。
目前bypass仅支持索引扫描,以及几个简单算子的简单排列,通过相关GUC参数可额外支持Agg、Sort、分区表等部分功能,不支持JOIN。此部分可阅读代码 getFusionType() 进行了解。
观察一个SQL是否是走了bypass,可以通过explain,观察计划是否带[bypass]
标签,也可通过相关参数了解检查未通过的原因。例如:
一些相关的GUC功能:
opfusion_debug_mode
:用于在explain中打印不满足bypass的原因。
enable_beta_fusion
:开启后可以额外支持AGG、SORT算子的部分功能。
sql_beta_feature
:一些beta特性,设置 PARTITION_OPFUSION 之后,可以额外支持分区表。
并行查询
并行查询即使在一个SQL内,使用多个线程并行完成。
通过参数query_dop
控制,1表示单并行,即功能关闭,> 1表示并行度。目前暂无法动态的更改并行度,设置多少就是多少。
并行查询能够将数据分批后并行计算,可以成倍的提升一条sql的性能,当然也并非所有的SQL都可以并行,需要根据算子、计划实际分析看待。
显而易见,其使用的场景主要是复杂查询,对于简单的单点查询,并不会有什么效果。
向量化执行
传统的火山模型执行流程,每次流动的仅有一个元组,而向量化执行则为每次计算一批元组。
向量化执行主要用于对列存场景进行计算,因此其数据结构、计算单元的设计都是面向列存的。
而对于行存表场景以及行列存都存在的场景,目前的方案是实现了一对行列转换算子(VecToRow、RowToVec),将行存数据转换为向量化计算的Batch,进而使用向量化引擎进行计算。
在行存下,通过开启参数force。。。
可以强行走向量化执行,但是其查询计划并非是代价递推生成的,而是先生成的行存计划,之后直接对行存计划进行直接改造,因此得到的向量化计划并不一定是比较好的。
向量化的计算会比逐行计算的模式快很多,但行列转换算子却会又带来额外的消耗,且目前消耗比较重。因此向量化执行并不一定能带来性能的提升,需要看这两部分的找补抵耗情况。