A parallel-query toggle, and one of the more interesting members of the enable_* family to flip, because what it switches off has a clean, predictable replacement. Default on, context user, same family caveat as enable_async_append: a diagnostic instrument, not a tuning knob.

Two of the youngest members of the enable_* family, and a natural pair: both let the planner reorder the keys of a multi-key operation to make sorting cheaper, and both default on, user context, with the family caveat from enable_async_append — diagnostic probes, not production knobs.

The idea behind both is the same, and it’s a nice one.

Cygnet is a small, fierce, PostgreSQL-only ORM for async Python, and its whole personality is that it refuses to hide the SQL. Most ORMs exist so you never have to think about the query; Cygnet exists for the opposite kind of person, the one who already knows what SQL they want and would just like some help writing it without

Two more enable_* planner toggles, and they belong together because the thing they switch off is, in both cases, an index — the difference is how the index gets used. Both default on, both are user context, and both carry the family warning from enable_async_append: these are diagnostic instruments, not tuning knobs. You flip them in a session

We arrive at the enable_* parameters, a family of two-dozen-odd planner toggles that all default to on and all share one crucial property: they are not tuning knobs. They are diagnostic instruments. Each one switches off the planner’s ability to consider a particular plan type, and the reason that capability exists is so that an engineer chasing a bad plan

waxsql generates SQL the way a bowl of wax fruit fills a centerpiece: it looks real, it nourishes nothing, and it will never spoil. Every query it produces is type-correct against a real PostgreSQL schema and computationally pointless, which is exactly what you want when you are fuzzing a query rewriter, beating on a parser, or generating a reproducible workload

Most parameters that change across versions change their default. effective_io_concurrency is rarer: it has changed its meaning twice, and what it governs in PostgreSQL 18 is not what it governed in 17, which in turn was not what it meant before 13. A value you copied from a 2019 tuning guide into a modern cluster is not just stale

This is one of the most consistently misunderstood parameters PostgreSQL has, and the misunderstanding is always the same shape: people believe effective_cache_size does something to memory. It allocates a cache. It reserves RAM. It controls how much PostgreSQL keeps in memory. It does none of these. It allocates nothing, reserves nothing, and changes no runtime behavior whatsoever. It is

dynamic_shared_memory_type picks the operating-system mechanism PostgreSQL uses for dynamic shared memory — memory allocated after startup, as opposed to the fixed shared_buffers region grabbed once at boot. The context is postmaster, so it’s a restart to change, and the default is chosen by initdb from what your platform supports: posix on Linux and most Unix, windows on Windows. You

dynamic_library_path tells PostgreSQL where to look for a loadable C module when something — a CREATE FUNCTION ... LANGUAGE C, a LOAD, a shared_preload_libraries entry — names the library by a bare filename with no directory in it. The default is $libdir, the context is superuser, and for most of its life this was a parameter