19把JIT的默认设置改为off。以前依赖默认开关、且确实从编译获益的长分析查询，需要重点比较；主键点查和短事务不一定变慢，原来就关闭JIT的环境通常也不会因此改变行为。

JIT没有被删除。查询先付出生成本地代码的时间，之后必须省回更多执行时间，整体才值得。默认关闭只是改变是否默认采用，不能简单理解成取消优化。

一、JIT 到底加速哪一部分？

即时编译可以借助LLVM，为部分表达式计算和行解析生成专用本地代码。好比先做一份针对这条查询的程序，再靠后续大量计算省时间；工作越短，前面的准备就越可能不划算。

它不会替你补索引，也不会自动消除网络延迟、磁盘瓶颈或锁等待。一个只读取几行的短查询，如果为编译多花数毫秒，就可能比直接执行还慢。选择 JIT 的依据应是具体工作负载，而不是表很大或者 SQL 很长。

二、哪些项目需要特别留意？

19 的发布说明指出，过去按优化器估算成本触发 JIT 的方式并不总能可靠反映收益。因此，对于大量分析查询的站点，升级后需要主动确认是否重新启用。

三、先查实际配置，不要只看默认值

SHOW jit反映当前会话实际值。参数可能来自实例配置、数据库设置、角色设置或连接建立后的 SET。默认值改成 off，不代表每个已经配置过的环境都会自动关闭。

pg_jit_available()用于确认当前安装是否具备可用 JIT 支持。若程序没有相应实现或组件，仅执行 SET jit = on 也不能凭空得到编译能力。

四、怎样做一次有意义的对比？

在测试环境选一条真实的只读分析查询，保持数据、并发和其他参数一致，分别运行两组测试。下面的表名和聚合字段需要替换成自己的对象：

第二组只把 jit = off改为 jit = on，其余保持一致。EXPLAIN ANALYZE 会真正执行查询，因此要先选择可承受执行成本的测试数据和时间窗口。

打开开关后没有出现 JIT 信息，不一定是出错。查询估算成本可能没达到门槛。若需要研究编译本身的影响，可以在隔离测试中临时降低门槛；不要把强制编译的实验参数直接搬到生产。

比较时记录查询总时间、编译花了多久，以及数据是从内存还是磁盘读取。两组交替跑几次：第一次可能还在读磁盘，第二次数据已经进内存，不能把这部分差别算成 JIT 的功劳。只快过一次，也不足以证明以后都更快。

如果程序使用预处理语句和通用计划，部分 JIT 决定发生在生成计划时。做对比时应使用新会话或重新准备语句，避免旧计划影响判断。

五、确认有收益后，如何启用？

先在特定报表会话尝试开启，记录并发情况下的CPU消耗与完成时间，确认有收益后再考虑专用角色的默认值：

角色设置主要作用于之后创建的连接。连接池已有会话要按实际管理方式重建或单独设置；如果测试不理想，可撤销这项角色配置：

不要为一条报表而大幅降低全实例的编译门槛。应兼顾报表耗时与短请求响应，把旧版实测数据保留下来再对比，比讨论开关本身更能判断收益。