Skip to content

jit

Allows PostgreSQL to use just-in-time compilation when the build provides a JIT implementation and the plan’s estimated cost crosses the configured thresholds. Enabling it does not force JIT for every query.
Note

Fact — official short description: “Allow JIT compilation.”

Identity

Type , Valuebool
Upstream pg_settings type
Context , Valueuser
Settable by an ordinary user
Unit , Value
Raw unit
Range , Value
Raw limits in the last observed version
Enum values , Value
— for non-enum types
Category , ValueQuery Tuning / Other Planner Options
Upstream classification
Latest boot value , Valueoff
off

Lifecycle

Fact Value
First observed PG11
Present in PG11–19 Beta 3
Removed in No
Introduction commit 432bb9e04da4 — Basic JIT provider and error handling infrastructure.
Commit date 2018-03-21
Discussion thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG11 off off
PG12–18 on on
PG19 Beta 3 off off

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload Guidance
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.
OLAP Keep it available and benchmark CPU-heavy aggregates, expressions, and scans. Judge total execution time, including generation, inlining, optimization, and emission overhead.
Small nodes 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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template Effective value Versus upstream boot Source expression
OLTP Unmodified
OLAP Unmodified
CRIT Unmodified
TINY Unmodified
Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG11–19 Beta 3 unmodified; OLAP: PG11–19 Beta 3 unmodified; CRIT: PG11–19 Beta 3 unmodified; TINY: PG11–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

  • 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.

jit_above_cost · jit_inline_above_cost · jit_optimize_above_cost · jit_provider · plan_cache_mode · jit_expressions

References