Reaching for enable_sort = off because a query has a slow sort in it is usually aiming at the wrong target. When a sort is slow, it is generally because it spilled to disk, which is a work_mem problem. When a sort genuinely should not be there at all, the fix is an index. enable_sort changes neither of those, and

enable_seqscan does not disable sequential scans. It cannot, and it was never meant to. The documentation says as much: sequential scans cannot be suppressed entirely, because sometimes reading the whole table is the only way to answer the query. What off actually does is tell the planner to avoid a sequential scan when it has any other option. That is

You are rarely the only thing writing your SQL. Your ORM writes some of it, your nested views write more, and sooner or later one of them joins a table to itself on its own primary key. That join returns exactly the rows it started with. enable_self_join_elimination is the PostgreSQL 18 optimization that notices and deletes it.

Default on

Here is a log line from a PostgreSQL 14 database that PostgreSQL 14 cannot produce:

1
ERROR: role "postgres" cannot SET ROLE to "rds_superuser"

The context: Amazon RDS, a major-version upgrade done through logical replication, with a reverse subscription pointed back at the old primary so we could fall back if the cutover went badly. Standard

enable_presorted_aggregate is on, it has been on since PostgreSQL 16 introduced it, and the single most useful thing you will ever do with it is turn it off for exactly one query.

Default on, context user: settable per session, per role, per database, or inline in a single transaction. That last option is the entire recommendation,

The sibling of enable_partitionwise_aggregate, and it shares that parameter’s defining trait: it defaults off, for the same reason. So rather than repeat the off-by-default argument in full, this post covers what’s different — the mechanism, a benefit the aggregate version doesn’t have, and a precondition strict enough to be the main reason the feature doesn’t fire when people

A partitioning optimization, and a notable exception in the enable_* family: it defaults off. Almost every other member of the family defaults on and exists so you can switch a capability off for diagnosis; this one defaults off and exists so you can switch a capability on when you’ve decided it’s worth the cost. That inversion — and the

One of the genuinely important partitioning parameters, and one you should understand rather than merely leave on — because it does its work at two different times, and the difference determines how much it can help your queries. Default on, context user, same family framing as enable_async_append: a diagnostic instrument, not a tuning knob. It’s the

A parallel-query toggle that refines the hash join from enable_hashjoin, and it rewards a moment of precision, because “a hash join running in parallel” and “a parallel hash join” are two genuinely different things. Default on, context user, same family framing as enable_async_append: a diagnostic instrument, not a tuning knob.

Back to parallel query, and a parameter easy to confuse with the family’s opener. enable_async_append was about running foreign scans concurrently across remote servers. This one is about running local Append children concurrently across worker processes. Different mechanism, different problem, similar-sounding name. Default on, context user, same family framing: a diagnostic instrument, not a tuning knob.