jit_optimize_above_cost

jit_optimize_above_cost — Optimize JIT-compiled functions if query is more expensive. Observed in PG11–19 Beta 3; its last measured boot default is 500000 in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Optimize JIT-compiled functions if query is more expensive.”

Identity

Type , Valuereal: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value-1 – 1.79769e+308: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Planner Cost Constants: Upstream classification
Latest boot value , Value500000: 500000

Lifecycle

Fact	Value
First observed	PG11
Present in	PG11–19 Beta 3
Removed in	No
Introduction commit	`cc415a56d09a` — Basic planner and executor integration for JIT.
Commit date	2018-03-22
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG11–19 Beta 3	`500000`	—	500000

How it works

jit_optimize_above_cost compares the finished plan’s estimated cost with a threshold to decide whether PostgreSQL may run expensive JIT optimization passes. The cost is the planner’s arbitrary estimate, not milliseconds.

The decision occurs at plan time and only matters when JIT is enabled and a provider is available. Generic prepared plans retain the decision made when the generic plan was generated.

A value of -1 disables this stage. jit_inline_above_cost and jit_optimize_above_cost are additional gates after jit_above_cost, so setting either below the base compilation threshold is not meaningful. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Do not lower jit_optimize_above_cost globally to chase a single CPU-heavy statement. Compilation latency is visible in short-query tails; test at statement or role scope and include JIT generation time in the result.
OLAP	For long CPU-bound queries, benchmark total elapsed time on both sides of jit_optimize_above_cost. Lowering the threshold is useful only when saved execution CPU consistently exceeds compilation overhead.
Small nodes	Keep the default or disable the stage with -1 when LLVM work competes with a small CPU budget. Estimated cost alone does not prove that JIT will pay back its startup cost.

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

Reading the threshold as milliseconds rather than arbitrary planner cost units.
Ignoring JIT generation, inlining, optimization, and emission time when benchmarking.
Expecting a changed value to alter a generic plan that was already generated.
Setting an advanced-stage threshold below jit_above_cost and expecting that stage to run by itself.

jit · jit_above_cost · jit_inline_above_cost · jit_expressions