jit

Definition PG 18 manual

Determines whether JIT compilation may be used by PostgreSQL, if available (see Chapter 30). The default is on.

How it works

The jit switch is the top-level gate. When it is on, jit_above_cost decides whether compilation starts, while jit_inline_above_cost and jit_optimize_above_cost govern additional, more expensive compilation work.

JIT is mainly beneficial for long-running CPU-bound queries, often analytical ones. Compilation adds latency, so short statements can become slower if thresholds are lowered too aggressively.

The decision is made at plan time. For a prepared statement using a generic plan, the settings active when that plan is prepared control the decision; EXPLAIN ANALYZE reports whether JIT ran and how much time its phases consumed.

Operational considerations

jit=on does nothing if PostgreSQL was built without an available JIT implementation.

On does not mean every query is compiled; cost thresholds still gate execution.

Lowering thresholds can make short queries slower than interpreted execution.

Generic prepared plans use the configuration in effect when the plan was prepared.

Estimated cost is not execution time, so threshold behavior must be measured with representative plans.

Workload guidance

OLAP: Keep it available and benchmark CPU-heavy aggregates, expressions, and scans. Judge total execution time, including generation, inlining, optimization, and emission overhead.

OLTP: Leave the default thresholds high or disable JIT if compilation latency appears in short-request tails. Test at the statement or role level before changing it cluster-wide.

SMALL: On small CPU-constrained systems, JIT often has little benefit for ordinary queries. Keeping it on with conservative thresholds is different from lowering thresholds to force compilation.