Update 20210928_07.md

Author: digoal

202109/20210928_07.md

@@ -19,15 +19,15 @@ PostgreSQL , 统计信息 , 快照 , SQL执行计划
 
 2、问题点背后涉及的技术原理    
 - PG SQL 的执行计划是怎么生成的?     
-    - 通过SQL统计信息、结合PG的一些代价系数参数设置、通过公式计算cost, 最后选择cost最低的plan作为plan tree.  (多表JOIN触发geqo的除外)    
+    - 通过SQL统计信息、结合PG的一些代价系数参数设置、通过公式计算cost, 最后选择cost最低的plan作为plan tree.  (前面说的是穷举法, 多表JOIN可选顺序组合太多, 将根据参数配置触发geqo算法)    
 - PG SQL 是按什么执行计划执行的?     
     - 如果时generic plan, 则按cached plan执行.      
     - 如果cached plan算出来的代价大于custom plan的avg(cost), 则使用custom plan(相当于硬解析).     
         - [《执行计划选择算法 与 绑定变量 - PostgreSQL prepared statement: SPI_prepare, prepare|execute COMMAND, PL/pgsql STYLE: custom & generic plan cache》](../201212/20121224_01.md)      
 - 使用绑定变量时就一定会用会话中已经缓存的执行计划吗?     
     - 不一定, 参考如上. 如果cached plan算出来的代价大于custom plan的avg(cost), 则使用custom plan(相当于硬解析).        
 - 怎么知道过去某个时刻当时SQL的执行计划?      
-    - 不知道, 除非打印出来.  例如, 使用auto_explain插件      
+    - 不知道, 除非打印出来.  例如, 使用auto_explain插件.        
 
 3、这个问题将影响哪些行业以及业务场景    
 - 通用    
@@ -45,6 +45,9 @@ PostgreSQL , 统计信息 , 快照 , SQL执行计划
     - 加快统计信息收集频率, 避免统计信息不及时造成的query plan不正确.     
     - 分析型的业务设置plan_cache_mode为force_custom_plan, 避免大量数据的变化统计信息频繁变化, 导致cache plan不争气的问题. force_custom_plan要求每次执行SQL时都重新生成query plan.     
         - [《PostgreSQL 11 preview - 增加强制custom plan GUC开关(plan_cache_mode)，对付倾斜》](../201803/20180325_06.md)      
+- 偶尔导出统计信息, 用来计算过去SQL的执行计划. 但问题是颗粒度有限.  
+    - [《PostgreSQL 统计信息pg_statistic格式及导入导出dump_stat - 兼容Oracle》](../201710/20171030_02.md)
+    - [《PostgreSQL 统计信息(dbms_stats)导出，导入，锁定，替换》](../201903/20190318_06.md)  
 
 6、业务上避免这个坑牺牲了什么, 会引入什么新的问题      
 - auto explain 开启后, 会打开时间计数器, 影响全局. 导致性能下降.        
@@ -54,6 +57,7 @@ PostgreSQL , 统计信息 , 快照 , SQL执行计划
 7、数据库未来产品迭代如何修复这个坑      
 - 希望内核可以支持统计信息、元数据信息快照功能，用于回放SQL，得到过去的执行计划信息。        
     - 例如当统计信息发生较为剧烈的变化时, 打个快照
+    - 未来版本可能会支持, 可以看到一些端倪: [《PostgreSQL 18 preview - Pluggable cumulative statistics》](../202407/20240713_05.md)  
 - 当query执行计划发生变化时, 通过参数控制, 例如SQL执行时间抖动超过多少时, 可以将前后的plan tree打印到日志中, 同时输出类似auto_explain的详细内容.   
 - auto_explain 支持按query id来设置不同的阈值, 或者按cost和query time的抖动比例来进行设置和记录.   
     - 总之就是记录真正的异常, 排除噪音.