POSTGRESQL 的灵活性想必是众人皆知的事情，扩展方式的数据库在功能方面是有很多益处的。
PG_SHOW_PLANS 是通过插件的方式，插入到POSTGRESQL 目前支持PG 10 PG11 PG12 PG13 等版本，如果你还继续使用10以下的PG版本，看来是该换换的时候了。
PG_SHOW_PLANS 通过 客户访问PG的进程中设置 HOOK， 将执行语句的执行计划直接保存在 SHARED BUFFER 中，并通过 pg_show_plans 来将计划展示
安装上和其他的
直接MAKE&MAKE INSTALL 后 ，在配置文件中的 shared_preload_libraries中添加 pg_show_plans，添加在对应的数据库启动后，进行extension
通过和pg_stat_activity 语句联合，可以快速的查出当前执行的语句中的语句的执行计划
粗略看，仅仅是对执行计划的展示但实际上，对于解决问题是非常有效的，如我们在查看pg_stat_activity 的时候配合show plans 可以直接查看执行的计划，加快问题解决的速度，并且执行计划是实际的语句当下的执行计划，对处理问题的准确性也有提高。
同时也可以将语句的执行计划进行存储，配合pg_stat_statement，或者日志的慢语句查询，将问题进行联合处理。
本次数据库大会上，某位银行的数据库管理者，一直在提及ORACLE 和 MYSQL 之间的差距，尤其提及MYSQL 在数据库历史信息方面和ORACLE 之间的差距，这点也是PG 数据库需要注意的，如何存储更多的历史信息，在问题发生后，有据可查有历史数据可以进行分析，才是需要做的。
这里需要注意几点
1 PG_SHOW_PLANS 是视图， 其中的PID 和PG_STAT_ACTIVITY 的PID 是一一对应的，
2 通过 USERID DBID 等信息可以获得数据的可以定位哪个用户在哪个数据库上执行的语句。
3 PG_SHOW_PLAN 本身支持两种PLAN 的展示方式 TEXT 或 JSON的方式，并且最大支持8192 BYTES 的执行计划的存储。
PG_SHOW_PLAN 有四个函数可以调用
PG_SHOW_PLANS_DISABLE(), 主要的使用方式是在SESSION 级别关闭PG_SHOW_PLAN, PG_SHOW_PLANS_ENABLE() 是打开 PG_SHOW_PLAN功能，同时还有两个函数是指定展示的方式是JSON 或者TEXT 。
相对来说PG_SHOW PLAN 还是比较灵活的。
