前言
为什么使用pg_hint_plan或者什么时候使用pg_hint_plan？
这要从优化器的局限性谈起：
PostgreSQL 使用基于成本的优化器（cost-based optimizer），该优化器依赖于数据统计而非静态规则。
规划器（优化器）会估算每个可能的 SQL 语句执行计划的成本，然后执行成本最低的计划。
尽管优划器尽力选择最佳执行计划，但它并不完美，特别是在复杂场景下cost预估可能会出现偏差，
这也就是为什叫做代价预估，可能执行计划实际上并不是最优的。
使用过Oracle的朋友应该都了解过SPM（sql plan manangement），其使用一种称为SQL计划基线（SQL plan baseline）的机制，它是优化器允许对SQL语句使用的一组可接受的计划。是一种预防机制，使优化器能够自动管理执行计划，确保数据库仅使用已知或经过验证的计划。目前在PG中还没有类似的能力，优化器根据cost预估的最小代价选取最优路径作为最终执行计划来执行，对于cost预估偏差的场景，可能就会导致一些突发性的性能劣化问题。
对于统计信息不准导致的cost预估偏差，我们通常收集统计信息来解决。
但比如优化器本身cost预估逻辑在某些场景下过于理想化导致的偏差，收集统计信息就无法解决了。
优化器固然强大，但它不是万能的。
我们通常会使用guc参数来影响执行计划，比如enable_mergejoin = off，这样sql就不会走mergejoin了
但是这类guc参数使用起来不够灵活，需要单独设置，不能很好的和SQL相结合，通常session级设置。
pg_hint_plan具有丰富的hint种类，在不影响语义的情况下hint作为sql的一部分一起执行。
我们甚至可以使用hint_table来固化sql执行计划，也可在sql语句中不拼写hint的情况下使用hint
对于一些不能轻易修改sql的业务来说是比较友好的。
原理
pg_hint_plan配置在shared_preload_libraries参数中，Postmaster主进程起动时会加载对应的so，
并注册_PG_init函数中的自定义参数以及hook函数。
当使用hint时，是通过hook函数结合内核disable_cost对plantree进行修改，从而按预期指定执行计划。
小结
本文简单介绍了pg_hint_plan的核心原理，及使用场景，算是pg_hint_plan技术内幕系列的开篇吧。后续的文章会继续深入探索scan method、join method、join order这几种hint的原理。
