The jit_* family closes with the three parameters for people working on the JIT itself rather than with it. All three are booleans, all default off, all date to the original PostgreSQL 11 work, and all live in Developer Options. What makes them worth a post at all is that one of them is genuinely fun, and the other

Here is a fact about PostgreSQL that surprises even people who have been running it for years: every query against a table takes a lock on every index on that table, whether or not the query uses any of them.

This is usually harmless. The locks are AccessShareLock, the weakest lock there is; they conflict with almost nothing,

The third cluster of the jit_* family is the one that decides when JIT happens, and it is where the trouble lives. All three arrived with the subsystem in PostgreSQL 11, all three have context user, and all three are denominated in planner cost units, that dimensionless currency anchored to seq_page_cost = 1.0. When the planner finishes

Continuing through the jit_* family in logical clusters: this pair decides what JIT compiles, and you have already seen their names, because they are the “Expressions true, Deforming true” printed in every JIT block the last post showed. Both are boolean, context user, default on, part of the original PostgreSQL 11 JIT work, and filed under Developer Options,

The io_* parameters we’ve covered so far describe the I/O requests: how big each one is, how many a process may have in flight. These two decide who actually performs them. I wrote about the architecture, and about what PostgreSQL 19 does to it, in AIO Grows Up; this is the parameter-level view, and it includes a

effective_io_concurrency is a request. io_max_concurrency is the grant.

New in PostgreSQL 18 as part of the asynchronous I/O subsystem, io_max_concurrency is the hard ceiling on how many I/O operations a single process can have in flight at once. Not per cluster; per process. The context is postmaster, so changing it requires a restart, and the default is -1

We now enter the io_* neighborhood, the newest one in the GUC namespace: nothing here existed before PostgreSQL 17. If effective_io_concurrency answers “how many I/Os do we keep in flight?”, io_combine_limit answers the orthogonal question: “how big is each one?” Depth and width.

io_combine_limit arrived in PostgreSQL 17. The default is 128kB (16 blocks; unitless values are in BLCKSZ

IntervalStyle is DateStyle’s younger sibling, and it inherited the family trait: it looks like an output-formatting preference, but it also changes how PostgreSQL parses your input. We covered the date version of this trick in DateStyle. The interval version is less famous and, in one specific case, nastier.

The default is postgres, the context is user

Every connection anyone has made to a PostgreSQL server since 8.0 has opened with the server announcing, unprompted, the value of integer_datetimes. Since PostgreSQL 10, the value it announces is the only value a PostgreSQL server can be built with, and the current documentation disposes of the entire subject in one sentence: “As of PostgreSQL 10, this is always