杨向博-pg_hint_plan技术内幕——解锁hint优化的核心原理.pdf

1、/2025.01.04/pg_hint_plan技术内幕-解锁hint优化的核心原理杨向博PostgreSQL ACEhint优化的必要性为何选择pg_hint_plan内核原理揭秘pg_hint_plan的工作机制总结与展望pg_hint_plan及执行计划的未来CONTENThint优化的必要性/2025.01.04/hint优化的必要性CBO优化器避免不了cost预估偏差index scan run_cost:对于统计信息不准 -收集统计信息对于计算公式导致的偏差 -guc修正cost（不够灵活）COST预估=1.统计信息&2.计算公式/2025.01.04/丰富的hint类型，灵活地与

2、SQL相结合hint优化的必要性内核原理揭秘/2025.01.04/pg_hint_plan配置在shared_preload_libraries参数中，Postmaster主进程起动时会加载对应的so，并注册_PG_init函数中的自定义参数以及hook函数。当使用hint时，是通过hook函数修改plantree来改变执行计划。接下来我们将主要分析scan method、join method、join order内核原理揭秘-工作机制/2025.01.04/在讲具体hint之前，介绍下set guc影响执行计划的原理。其实在内核中，是利用disable_cost来调整cost的计算。在c

3、ostsize.c中，可以看到所有method对应的cost计算逻辑。Costdisable_cost=1.0e10;以set enable_indexscan to off 为例：在cost_index中当enable_indexscan为false时startup_cost+=disable_cost（10000000000）这样得到该indexscan的startup_cost会很大在后续优化器计算最小选择路径时，当前indexscan会被排除内核原理揭秘-disable_cost/2025.01.04/以IndexScan(table index.)为例：在set_rel_pathli

4、st时进入hook，pg_hint_plan处理rel的indexlist，只保留hint中指定的index，从list中delete其他unused index并将indexscan之外其他的scan method配置为disable_cost最后计算最小代价，确定最终的path因此，会存在一个现象。虽然hint中指定了使用某个index但最终没走索引扫描，而走了顺序扫描。因为hint指定index只是将表的其他索引从plantree中剔除只保留指定的这个索引，但走这个索引预估的代价不一定是最小。内核原理揭秘-Scan method/2025.01.04/如图这个sql:使用IndexSca

5、n(dba_users dba_users_username_idx)这个hint，最终没有走index，走了seqscan内核原理揭秘-Scan method/2025.01.04/ScanMethodHintParse:入参hint：IndexScan(dba_users dba_users_username_idx)内核原理揭秘-debug Scan method/2025.01.04/通过parse得到hint_keyword为HINT_KEYWORD_INDEXSCANhint-enforce_mask=2 即ENABLE_INDEXSCAN内核原理揭秘-debug Scan met

6、hod/2025.01.04/restrict_indexes:可以看到rel-indexlist的length为3，为dba_users表的3个索引内核原理揭秘-debug Scan method/2025.01.04/restrict_indexes:对indexlist的成员进行遍历，比较是否和hint相同，第一个成员和hint相同，标记use_index=true内核原理揭秘-debug Scan method/2025.01.04/restrict_indexes:第二个成员和hint不同，将其append至unused_indexes list内核原理揭秘-debug Scan m