背景
场景:
- HTAP业务, 企业级OLTP业务.
- ORM(自动生成SQL, 无法优化, 数十表的SQL JOIN)
挑战:
- 优化器弱无法选择最佳执行路径,
- 统计信息不及时, 无法得出最佳执行计划,
- 环境: ssd, disk 多种不同硬件组成的表空间, 怎么才能算出最佳代价
- 执行器弱支持的数据扫描、计算方法少的可怜.
PG 解决方案:
- 优化器强大
- 执行器强大
- 支持扩展执行器
- 支持并行计算、JIT
PG的将军之官 - 优化器
谋虑的前提?
- 数据 案例 逻辑 理想
JOIN :
穷举的问题: N的阶乘种组合方式, 表多会导致组合太多, 导致优化器根本算不出来
PG支持:
- JOIN数超过设定参数, 自动使用遗传算法(图、TSP经典问题的解法)
- 参数可设置, 使用固定顺序
- 默认穷举
- aqo插件, 类似机器学习, 适合非常复杂的SQL
join算法 :
- nest(普通, 物化)
- merge
- hash
- limit优化
in大量value优化
- hash sub sets
并行计算:
- 根据SQL的代价自动启用并行计算, 适合AP场景
- 什么时候用并行? 参数阈值决定.
- 多大并行? 自动根据代价、表的大小等相关值计算
jit:
- 根据SQL代价自动启用JIT, 适合计算记录数多、表达式多的AP型SQL
- 什么时候? 参数阈值决定, 当代价大于阈值, 自动使用JIT
扫描方法怎么选择:
- 索引扫描
- 位图扫描
- 全表扫描
- ctid扫描
- ctid range scan
- 物化扫描等
- ...
代价因子, 可自定义
- 适合任意硬件组合, 选出更佳的计划
选择性怎么评估?
- 自动生成统计信息(根据数据的变化量自动生成, 所以统计信息很及时)
- 统计信息柱状图
- 高频次分布
- 自定义统计信息
- 唯一值个数
- 字段和存储的线性相关性
prepared statement时倾斜怎么办?
- 自动调整
- 《执行计划选择算法 与 绑定变量 - PostgreSQL prepared statement: SPI_prepare, prepare|execute COMMAND, PL/pgsql STYLE: custom & generic plan cache》
- 《PostgreSQL plan cache 源码浅析 - 如何确保不会计划倾斜》
custom scan provider开放接口, 适合内置scan方法不能解决的特定workload场景:
- GPU, pg_strom, heterodb
- citus column store, pg_pathman都用了custom scan provider. 提升性能.
