The first of the three join-strategy toggles, so before we get to the parameter, a paragraph on the thing it sits inside: PostgreSQL has exactly three ways to join two tables, and for every join in every query the planner picks one of them. The three enable_* join switches — this one, enable_mergejoin, and enable_nestloop — let you take

The most consequential toggle in the enable_* family, because the thing it controls changed behavior in PostgreSQL 13 in a way that made some queries slower on upgrade — and enable_hashagg became, for a while, the lever people reached for to get the old behavior back. Default on, context user, same family framing as enable_async_append: a diagnostic

coddpiece is a relational-algebra teaching library for Python. You build an algebra expression by method-chaining; it compiles that expression to real SQL and runs it on any DB-API 2.0 connection, including the sqlite3 module that already ships with Python. The thesis is simple: learn the algebra first, and most of SQL’s apparent complexity turns out to be surface syntax over

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