jit = on, restart, run the API test suite. Same numbers as before. That was my first evening with PostgreSQL 11, released last week, and it was the correct result.
JIT is the loud feature of this release and the misunderstood one. Postgres can now compile expression evaluation into machine code through LLVM. People read “compilation” and expect their endpoints to get faster. They will not. A primary key lookup takes a fraction of a millisecond. There is nothing in it worth compiling, and the compilation itself costs more than the whole query. JIT is for the other kind of query: an aggregate chewing through millions of rows, where the same expression runs so many times that generating machine code for it pays back.
This is why it sits behind planner cost thresholds like jit_above_cost, and why in 11 it ships disabled. The planner estimates the query cost and decides if compilation is worth its price. When it fires, EXPLAIN ANALYZE shows a new JIT section with generation and inlining timings. You see what you paid and what you got.
Partitioning is the quiet feature and the useful one. Version 10 gave us declarative partitioning, honest but thin: no primary keys on partitioned tables, no default partition, pruning only at plan time. Version 11 fills the gaps. Hash partitioning, a default partition for rows that match nothing, unique constraints across partitions, pruning at execution time, so prepared statements and joins skip partitions too. My advice on native partitioning used to be “wait”. Now it is “try”.
The JIT part generalizes past Postgres. An optimization with a fixed upfront cost must know when not to run. The cost model is the feature. The compiler is just the part that gets the headlines.