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
PostgreSQL 19 ships with GRAPH_TABLE, an implementation of the ISO/IEC 9075-16:2023 SQL/PGQ standard. The shorthand version: you can declare a property graph over a set of relational tables, and then query that graph with pattern-matching syntax that looks a lot like Cypher, without leaving Postgres.
The longer version requires some context, because graph databases are one of those
constraint_exclusion controls a planner trick: when a table carries a CHECK constraint, the planner can compare that constraint against your query’s WHERE clause and, if the two contradict, skip scanning the table altogether. A CHECK (key BETWEEN 1000 AND 1999) on a child table means a query for key = 2400 provably has nothing to find there, so the planner
config_file tells the PostgreSQL server where postgresql.conf lives, which should make you squint for a second. If the server learns where its configuration file is from a parameter, and parameters come from the configuration file, how does it ever find the first one?
It doesn’t, and that is exactly why config_file is the one parameter in PostgreSQL you cannot
compute_query_id defaults to auto because the PostgreSQL developers were cornered. PostgreSQL 14 moved query-identifier computation into the core server so that everything wanting a query id, pg_stat_statements, pg_stat_activity, EXPLAIN, and the logs, could share one canonical value instead of each inventing its own. That left the question of what the default should be, and both obvious answers
For the better part of a decade, the answer to “does PostgreSQL support Transparent Data Encryption?” has been: not in the core, but EnterpriseDB has it, and Crunchy has a different one, and Cybertec has yet another, and you can roll your own with filesystem-level encryption if you do not mind that your DBA’s threat model and your auditor’s threat
commit_timestamp_buffers is the first, alphabetically, of seven parameters PostgreSQL 17 added to do the same job for seven different caches, so this post explains the job and the rest of the cluster can stay short.
The caches in question are PostgreSQL’s SLRUs (simple least-recently-used pools). These are small dedicated buffer pools, separate from the main shared_buffers, that cache
CVE-2026-2005, CVE-2026-2006, and CVE-2026-2007 are now patched. All three are heap buffer overflows in PostgreSQL or its bundled extensions. The pgcrypto bug — the headline one — has been sitting in the tree since approximately 2005, which means it is older than the iPhone, Twitter, and (for some of you reading) your career. Two of the three were found by
commit_delay is the one knob that tells PostgreSQL’s group commit to wait for a bigger group. The database already batches WAL flushes on its own: when one backend is flushing the WAL, others that become ready to commit queue up behind it and ride along on the same fsync. commit_delay makes the backend leading that flush pause for a
VACUUM FULL is not actually a tool you can use in production. It rewrites the entire table under ACCESS EXCLUSIVE lock, which means everything that touches that table (including the autovacuum worker that is, somewhere else in the system, probably the reason you needed VACUUM FULL in the first place) waits. On a serious table on a busy system, that