Sammlung von Newsfeeds

Postgres 18 introduced temporal keys (WITHOUT OVERLAPS, PERIOD).Postgres 19 expands (UPDATE/DELETE ... FOR PORTION OF) temporal capabilities further.

© Laurenz Albe 2026 (see here for more background)

Recently, I helped a customer investigate database problems. It turned out that these problems could be traced back to too many tables in the database. Since this may come as a surprise to many users, I thought it worth the while to write about it.

The problems that the customer observed

There were two problems that sounded like they might or might not be related to each other:

The most recent meeting of ISO/IEC JTC1 SC32 WG3 “Database Languages” took place from the 15th to the 19th of June 2026 in Stockholm. “WG3”, as we call it, works on standardizing the database languages SQL and GQL. In that meeting, a number of proposals that are of interest to SQL and PostgreSQL were accepted, which I want to report about here.

The third way to use an index, after the plain index scan and bitmap scan of enable_indexscan and enable_bitmapscan — and the one with the most-misunderstood catch, because an index-only scan can be physically possible and still end up reading the heap on nearly every row. Why that happens is the…

Upgrading PostgreSQL 19 clusters has become more seamless with tools like pg_upgrade and pg_createsubscriber, which together enable near-zero-downtime upgrades by first converting physical replicas into logical subscribers and then performing the upgrade with minimal service interruption.

Having written about the Swiss PGDay in 2024, I need not repeat all I said back then. Nonetheless, I'd like to share my impressions from the Swiss PGDay 2026 with you.

Picking Up Where We Left Off

In the previous post, I tried to lay out the framing half of this material: what actually counts as a disaster, why preparation and prevention aren’t the same as recovery, and how RPO and RTO end up being conversations with leadership rather than numbers an infrastructure team gets to declare on its own.

On June 23 2026, the London PostgreSQL Meetup Group met. Organized by:

• Valeria Kaplan
• Chris Ellis
• Alastair Turner
• Michael Christofides

Speakers:

Incremental sort exploits presorted data to avoid expensive full sorts, but cost estimation errors on skewed data can backfire.

Everyone knows not to store money as a double precision. One can hope. The rule is so well drilled that it has stopped being interesting, and it is also not where the trouble usually starts. The float is already in the schema before anyone weighs in on it: a measurement column someone later sums for a report, telemetry that drifts into a finance dashboard, a third-party feed ingested as double precision because that is how it arrived.

Step one in the quest for good transit in Kingston: hexagons, census data, and a whole lot of ST_Intersection.

Diagnose spilling hash joins with `enable_hashjoin = off`.

PostgreSQL 13 made hash aggregation memory-safe by allowing it to spill to disk — but that safety introduced a surprise regression for some queries on upgrade.

There is a misconception I keep running into, and it causes real harm in production. People are afraid to increase checkpoint_timeout. They think a longer timeout means a longer recovery after a crash. So they set it to 5 minutes. Some set it to 1 minute. And then they wonder why their Postgres is struggling. Let me dismantle this fear, argument by argument. First: serious people have a replica 🔗If you care about availability, you have at least one replica you can fail over to.

Why do we still waste time browsing YouTube and news sites looking for interesting content? Why rely on someone else's algorithm — when Claude, for instance, retains conversation history in one form or another and can therefore assess our actual interests? Maybe it's time to take control of shaping our own "information bubble"?

Learn relational algebra by building expressions that compile to real SQL.

We often hear that open source is about people.

People who contribute their time and, in a way, parts of their lives to work on software that is available for everyone without limitations and without licensing costs.

Postgres has had native support for declarative partitions since version 10, and every release since has filed off another rough edge. We got partition-wise joins, default partitions, hash partitioning, and the ability to attach and detach partitions concurrently. By any reasonable measure, declarative partitioning is one of the great success stories of modern Postgres.Despite the power here, it's always been a kind of one-way ratchet. Creating or dropping partitions was easy. But reorganizing existing ones was a different beast entirely.

Disable `enable_gathermerge` to diagnose whether a slow parallel query's bottleneck is the leader-side merge step or something deeper—like worker memory…