作者
digoal
日期
2021-11-29
标签
PostgreSQL , plan_cache_mode , 绑定变量缓存控制
视频回放: https://www.bilibili.com/video/BV1n341147vm/
场景:
- 在使用绑定变量的情况下, 每次SQL调用, 可能使用缓存的plantree, 也可能重新生成执行计划. 取决于根据传入参数和plantree估算出来的cost是否大于custom plan的平均值. 大于就使用custom plan.
- 《执行计划选择算法 与 绑定变量 - PostgreSQL prepared statement: SPI_prepare, prepare|execute COMMAND, PL/pgsql STYLE: custom & generic plan cache》
挑战:
- 可能导致执行计划错误, 性能抖动很严重. 甚至雪崩. 例如:
- 绑定变量的优势是避免每次SQL请求时都需要评估SQL plan带来的cpu开销, 在高并发的场景, 这个非常好可以节省cpu.
- 在存储过程中, 一个SQL需要LOOP调用, 而且每次调用前数据都发生了重大变更, 而且这种在一个事务中的多次调用, pg_stats无法及时的反映出来, 从而机制上就无法保障它能从plan cache变到custom plan.
- 在OLAP类的业务场景中, SQL相对来说比较复杂, plan带来的开销占整个SQL执行时长的比例很低, 所以即使客户端使用了prepared statement(很多时候程序员并不知道他们用了prepared statement)依旧建议用custom plan来应对变化的数据, 使得每次可以得到可靠的执行计划.
什么时候会用到绑定变量模式呢?
一种为隐式使用, 例如PL/pgSQL函数或存储过程中.
一种为显示使用, 例如驱动层的prepare statement.
PG解决方案:
- https://www.postgresql.org/docs/14/runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER
plan_cache_mode (enum)
Prepared statements (either explicitly prepared or implicitly generated, for example by PL/pgSQL) can be executed using custom or generic plans.
Custom plans are made afresh for each execution using its specific set of parameter values,
while generic plans do not rely on the parameter values and can be re-used across executions.
Thus, use of a generic plan saves planning time, but if the ideal plan depends strongly on the parameter values then a generic plan may be inefficient.
The choice between these options is normally made automatically, but it can be overridden with plan_cache_mode.
The allowed values are auto (the default), force_custom_plan and force_generic_plan.
This setting is considered when a cached plan is to be executed, not when it is prepared. For more information see PREPARE.
期望 PostgreSQL 增加什么功能?
类似Oracle RAC架构的PostgreSQL已开源: 阿里云PolarDB for PostgreSQL云原生分布式开源数据库!
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
