OID回卷并不常见，练习PG两年半的DBA小A，第一次练习OID回卷的问题，解决运行时长两年半的"慢sql"。

简单总结下auto_explain的原理：sql执行时插件的hook函数去调用explain对应的逻辑，然后打印执行计划到数据库日志。

当我们无法改写sql文本时，可以将hint文本写入到hint_table，在执行sql时会查询hint_table对应当前query_id的hint_str，接着去指定执行计划。因此，也可以说是hint_table有两个重要能力：1、不该写sql文本影响执行计划；2、实现全局共享执行计划。

join order也就是leading hint的逻辑相对复杂一点，从原理上看也是在hook函数中，将不同与leading hint的join path的startup_cost配置为disable_cost，这样最小代价就是hint所指定的join顺序，就实现了指定join顺序。

Join method的原理，其实就是对hint指定的几个表，将hint之外的join方式的startup_cost配置为disable_cost，这样最小代价就是hint指定的join方式了。

笔者很多次遇到由于disable_cost不够大，导致无法使用hint强制走指定的索引的场景，本篇尝试将其设置为一个guc参数可以动态调整，对于这样的场景就能够精准打击。当然指定的索引对于查询条件来说要是合理的。

本文我们将深入探索hint中scan method的原理。以IndexScan(table[ index...])为例在set_rel_pathlist时进入hook，pg_hint_plan处理rel的indexlist，只保留hint中指定的index，从list中delete其他unused index，并将indexscan之外其他的scan method配置为disable_cost。最后计算最小代价，确定最终的path。

本文简单介绍了pg_hint_plan的核心原理，及使用场景，算是pg_hint_plan技术内幕系列的开篇吧。后续的文章会继续深入探索scan method、join method、join order这几种hint的原理。

建表时如果同时创建主键等ixconstraints，并且指定了表的表空间，没有指定ixconstraints的表空间，PG默认会将ixconstraints放到默认表空间，而不是跟随表。本文就是对一行为的修改，默认让ixconstraints跟随表的表空间。

我们使用PG在create tablespace时需要提前手动创建表空间目录并授权给PG用户，这样很麻烦。本文尝试增加了create tablespace时自动创建表空间的能力，这样省事多了。

对于postgres_fdw是否会将where条件下推至remote执行有一些规则。 where条件中如果使用到了插件对应的function、operator、type等，那么首先在server的option里要配置这个extension。 满足这几种条件就不会下推至remote： 1、foreign_expr_walker函数返回false； 2、表达式的有效排序规则不是由foreign var产生的； 3、包含任何可变函数的表达式不能被发送，因为它的结果不稳定。

优化器代价预估过于理想化，导致order by col limit n代价计算偏差大，可尝试修改计算公式修正cost计算。

PG的RLS也是将对应的策略动态转换为where子句，在查询重写阶段将安全策略拼接到parsetree，生成执行计划去执行。

新增wait_event_start，这样就能得到每个等待事件相对准确的的“等待”时间，对于一些异常分析或者是功能调试来说是有意义的。

数据库内核本身支持了vacuum full 操作之前做空间预检查。如此一来，便可避免在某些客观因素下，因磁盘告警失效而进行的vacuum full操作导致磁盘被写满的情况发生，从而显著地提升了该维护操作的可靠性。