After the fsync abyss, something genial. DateStyle controls how PostgreSQL prints dates and how it resolves ambiguous date input, and the only thing you really need to know about it is: leave it on ISO, and the rest is interesting trivia.

The default is ISO, MDY. Context is user, with PGDATESTYLE as the environment variable libpq

PostgreSQL has ANALYZE. You run it (or autovacuum runs it for you), it draws a sample of 300 × default_statistics_target rows, and it writes a row per column into pg_statistic: a null fraction, an n-distinct estimate, a most-common-values list, an equi-depth histogram, and a physical-vs-logical correlation. The planner reads those numbers, multiplies selectivities together, costs a handful of

data_sync_retry is a boolean, it defaults to off, and its context is postmaster so changing it needs a restart. You will almost certainly never change it. It exists as the visible scar tissue from the single most unsettling thing the PostgreSQL community ever learned about its own durability assumptions, and to explain a one-line setting we have to explain

What is the point of this one? SHOW data_directory_mode reports the Unix permission bits on the data directory — 0700 or 0750 — and that is the entire extent of what it does. It’s read-only; you can’t set it. And it reports a fact that ls -ld $PGDATA would tell you just as well. So why is it a GUC?

data_directory names the location of the cluster’s data — the directory people mean when they write $PGDATA, the one holding base/, pg_wal/, global/, and the rest. Context is postmaster: settable in postgresql.conf or on the command line, never at runtime. And like a small handful of others, it cannot be set with ALTER SYSTEM —

A read-only preset, like block_size — SHOW data_checksums tells you whether the cluster has page checksums, and that’s the only interaction the GUC offers. But unlike block_size, this one has a thirteen-year history that’s still being written, and the history is the post.

When checksums are on, every data page carries a checksum that’s written when the page

Most of the planner cost parameters are about modeling the hardware — how expensive is a random page fetch, how expensive is a CPU cycle. cursor_tuple_fraction is different. It’s about modeling you: specifically, the planner’s guess at how much of a cursor’s result you actually intend to fetch.

The default is 0.1. Context is user. The

createrole_self_grant is small, recent (PostgreSQL 16), and almost impossible to explain in isolation. To say what it does, we have to talk about what the role system did before 16, what it does now, and why the change happened. The parameter is one of the visible artifacts of a fairly substantial overhaul, and that overhaul is more interesting than the

Fifth in a series of dispassionate tours of managed PostgreSQL services. Previously: RDS, Aurora, Cloud SQL, and AlloyDB. Azure’s current general-purpose managed PostgreSQL has an HA mechanism that differs from every service covered so far, and the difference has teeth.

cpu_tuple_cost, cpu_index_tuple_cost, and cpu_operator_cost are three of the constants the planner uses to price a query, and the single most useful thing to know about all three is that you should almost certainly never change them. The rest of this post is why.

PostgreSQL’s planner does not estimate query time in milliseconds. It estimates an abstract cost