32.2. When to JIT?
Prev | Up | Chapter 32. Just-in-Time Compilation (JIT) | Home | Next

## 32.2. When to JIT?

JIT compilation is beneficial primarily for long-running CPU bound queries. Frequently these will be analytical queries. For short queries the added overhead of performing JIT compilation will often be higher than the time it can save.

To determine whether JIT compilation is used, the total cost of a query (see Chapter 70 and Section 19.7.2) is used.

The cost of the query will be compared with jit_above_cost GUC. If the cost is higher, JIT compilation will be performed.

If the planner, based on the above criterion, decided that JIT compilation is beneficial, two further decisions are made. Firstly, if the query is more costly than the jit_optimize_above_cost GUC, expensive optimizations are used to improve the generated code. Secondly, if the query is more costly than the jit_inline_above_cost GUC, short functions and operators used in the query will be inlined. Both of these operations increase the JIT overhead, but can reduce query execution time considerably.

This cost based decision will be made at plan time, not execution time. This means that when prepared statements are in use, and the generic plan is used (see the section called “Notes”), the values of the GUCs set at prepare time take effect, not the settings at execution time.

### Note

If jit is set to `off`, or no JIT implementation is available (for example because the server was compiled without `--with-llvm`), JIT will not be performed, even if considered to be beneficial based on the above criteria. Setting jit to `off` takes effect both at plan and at execution time.

EXPLAIN can be used to see whether JIT is used or not. As an example, here is a query that is not using 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)

Given the cost of the plan, it is entirely reasonable that no JIT was used, the cost of JIT would have been bigger than the savings. Adjusting the cost limits will lead to JIT use:

    =# 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
       Generation Time: 1.259 ms
       Inlining: false
       Inlining Time: 0.000 ms
       Optimization: false
       Optimization Time: 0.797 ms
       Emission Time: 5.048 ms
     Execution Time: 7.416 ms

As visible here, JIT was used, but inlining and expensive optimization were not. If jit_optimize_above_cost, jit_inline_above_cost were lowered, just like jit_above_cost, that would change.

Prev | Up | Next
32.1. What is JIT compilation? | Home | 32.3. Configuration