Neues vom PostgreSQL Planet

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…

The Night When Things Almost Went Down

Have you ever left for home on a Friday evening feeling confident about your work for the day, at peace knowing your system would survive the coming weekend? We’ve all felt that way at some point.

Meanwhile, the disk on the server had quietly reached 90% utilization. Write-Ahead Log (WAL) files had accumulated enormously, one long-running query had been running for over an hour, and nobody noticed because, some time earlier, the dashboard had looked fine.

In the previous post, we discussed the basic syntax of graph queries in PostgreSQL 19 and discussed some simple SQL/PGQ examples. However, more often than not applications are more complex and need more than just two basic tables. Therefore, we want to dig a little deeper and see how we can write more complex queries and model some more sophisticated graphs based on real world scenarios.

Reorder GROUP BY and DISTINCT keys to cut comparison costs and skip sorts—new optimizations in PostgreSQL 17 and 18 that usually stay invisible but…

Part 2: Planning, Tool Use, and Reflection

Key takeaways

Cygnet is a PostgreSQL ORM for async Python that refuses to hide the SQL.

AI agents are becoming increasingly capable at operational tasks: summarizing logs, analyzing query plans, identifying anomalies, and assisting with incident response. For databases in particular, this creates an obvious opportunity. Much of day-to-day troubleshooting follows repeatable workflows that lend themselves well to automation.

Every database eventually runs into the same wall: storage costs money, and the data nobody queries anymore costs exactly as much as the data everyone does. A five-year-old row occupies the same expensive block storage as the order that came in thirty seconds ago. Postgres doesn't know the difference, and why would it? That's honestly a common refrain among most database engines.As a result, many have dreamed of fixing this by decoupling compute from storage.

Before starting, I want to put a few things at the top:

Diagnose index scan performance problems by temporarily disabling index scans or bitmap scans and measuring what the planner chooses instead.

I’ve got a new post over on the ClickHouse blog today: What’s New in pg_clickhouse v0.3.2: Postgres 19, TLS, Regex, and Memory. The big news is Postgres 19 support:

PostgreSQL today looks very different from the PostgreSQL many of us started working with over 25 years ago.

A couple months back I posted about maybe adjusting random_page_cost to better reflect how current storage handles random and sequential access. I had a bunch of great discussions about the topic since then, but ultimately I got distracted by other stuff.

Async append lets the planner fan out queries across remote shards in parallel instead of one at a time, but it's a diagnostic switch, not a tuning knob.

Generate valid SQL that looks real, nourishes nothing, and never spoils.

Introduction

I recently had the privilege of speaking at POSETTE 2026 about pg_stats and how Postgres internal statistics work. This post is a written companion to that talk – aimed at giving you a working understanding of what pg_stats is, how it’s populated, and how it shapes the decisions the query planner makes on your behalf.

Imagine a customers table that looks roughly like this:

On June 5 2026, the PostgreSQL User Group Greece met, organized by Eftychia Kitsou and Charis Charalampidi.

Speaker:

• George Capnias
• Kostas Maistrelis

PGDay Boston happened on June 9 2026 Organized by:

`effective_io_concurrency` has changed what it means twice—from a harmonic-series spindle count to a direct request depth to a real async I/O control.