JIT 编译主要对长时间运行且受 CPU 限制的查询有益。这类查询通常是分析型查询。对于短查询，执行 JIT 编译所增加的额外开销往往会高于它能节省的时间。
为了确定是否应使用 JIT 编译，会使用查询的总估计代价 （见Chapter 71和 Section 19.7.2）。 查询的估计代价会与 jit_above_cost 的设置值进行比较。如果代价更高， 就会执行 JIT 编译。之后还需要再做两个决定。 第一，如果估计代价高于 jit_inline_above_cost 的设置值， 查询中使用的短函数和操作符会被内联。第二，如果估计代价高于 jit_optimize_above_cost 的设置值，就会应用代价较高的优化来改进生成的代码。 这些选项中的每一个都会增加 JIT 编译的开销，但也可能显著减少查询执行时间。
这些基于代价的决定是在规划时而不是执行时作出的。这意味着，当使用预备语句并采用通用计划时（见PREPARE），控制这些决定的是预备时生效的配置参数值，而不是执行时的设置。
如果 jit 被设置为 off，或者没有可用的 JIT 实现（例如服务器在编译时未使用 --with-llvm）， 那么即使依据上述标准判断这样做会有收益，也不会执行 JIT。 将 jit 设为 off 会同时影响规划时和执行时。
EXPLAIN可用于查看是否使用了JIT。例如，下面的查询没有使用JIT：
=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Aggregate (cost=16.27..16.29 rows=1 width=8) (actual time=0.303..0.303 rows=1 loops=1)
-> Seq Scan on pg_class (cost=0.00..15.42 rows=342 width=4) (actual time=0.017..0.111 rows=356 loops=1)
Planning Time: 0.116 ms
Execution Time: 0.365 ms
(4 rows)
根据这个计划的代价，不使用JIT是完全合理的，因为JIT的代价会超过可能节省的时间。调整代价门槛后，就会使用JIT：
=# SET jit_above_cost = 10;
SET
=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Aggregate (cost=16.27..16.29 rows=1 width=8) (actual time=6.049..6.049 rows=1 loops=1)
-> Seq Scan on pg_class (cost=0.00..15.42 rows=342 width=4) (actual time=0.019..0.052 rows=356 loops=1)
Planning Time: 0.133 ms
JIT:
Functions: 3
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 1.259 ms, Inlining 0.000 ms, Optimization 0.797 ms, Emission 5.048 ms, Total 7.104 ms
Execution Time: 7.416 ms
可以看到，这里使用了JIT，但没有进行内联和昂贵的优化。如果jit_inline_above_cost或jit_optimize_above_cost也被调低，这种情况就会改变。