Latest Blog Posts

All Your GUCs in a Row: default_statistics_target
Posted by Christophe Pettus in pgExperts on 2026-06-12 at 01:00
Raise `default_statistics_target` from 100 to 500 and ANALYZE slows down forever — but sometimes that's the right call.

A thousand Postgres branches for $1
Posted by Tudor Golubenco in Xata on 2026-06-11 at 16:30
See how we reduced branching times from 20+ seconds to around a second and what use-cases these speed improvements enable.

Buildfarm Query API
Posted by Andrew Dunstan in EDB on 2026-06-11 at 16:15

A colleague asked me recently if there was an API for querying the PostgreSQL Buildfarm database. I told him there was not. I'm aware that a number of people have been scraping the web pages for data, so it seemed like there was a good case for something better. And with a little help from claude code, I create one. It's live now. There's a full description at https://github.com/PGBuildFarm/server-code/blob/main/API.md

I'm particularly interested to hear from people how this might be usefully extended.

Here's an example of use, getting the latest status for the member crake on the master branch

How the Other Half Plans
Posted by Christophe Pettus in pgExperts on 2026-06-11 at 15:00
Query planning is a two-job problem: rewrite your SQL into a better shape, then search billions of possible join orders for the cheapest one.

All Your GUCs in a Row: the debug_* family
Posted by Christophe Pettus in pgExperts on 2026-06-11 at 01:00
PostgreSQL's dozen `debug_` parameters are its own testing machinery, exposed as runtime settings.

Inside the pgEdge AI DBA Workbench: How Ellie Actually Works
Posted by Dave Page in pgEdge on 2026-06-10 at 11:38

TL;DR: The pgEdge AI DBA Workbench is four services on a shared Postgres datastore: a collector, a server, an alerter, and a React client that renders the dashboards and the chat panel where Ellie lives. Ellie is an agentic loop that drives any LLM you choose (Claude, ChatGPT, Ollama, or anything OpenAI-compatible) through a fixed set of database-aware tool calls. The model never queries Postgres directly, which is rather the point. Anomaly detection runs three tiers: z-score baselines, pgvector similarity against historical patterns, and LLM escalation for the residual cases. Source on GitHub under the PostgreSQL Licence.Most developers I talk to have a similar reaction when somebody tells them an LLM is going to manage their database: a polite nod, followed by a question about how the model is supposed to know the difference between a healthy snapshot on a quiet Tuesday and a runaway transaction on a Black Friday morning. It is a fair question, and it is the question we have been trying to answer whilst building the pgEdge AI DBA Workbench and its conversational interface, Ellie. You can run the Workbench as a pure monitoring platform with the AI switched off, and it is a perfectly capable one; but after months of working with Ellie enabled, none of us choose to.

Four Components and One Datastore

The Workbench is four Go and TypeScript services that share a PostgreSQL datastore. The collector daemon connects to each monitored instance and pulls dozens of metric probes covering , , replication state, and OS-level resource usage. Each probe writes to a dedicated time-series table indexed on and , with cadence configurable per scope.The server exposes a JSON-RPC 2.0 MCP and REST endpoints over HTTPS and brokers every interaction between the LLM and your databases. The alerter runs anomaly detection and threshold evaluation. The client is a React SPA that renders the dashboards, the cluster topology graph, and the chat panel where Ellie lives.One thing before the tool-use loop: MCP, the Model Context Protoco[...]

PGDay Boston 2026
Posted by Richard Yen on 2026-06-10 at 08:00

Introduction

PGDay Boston 2026 was a rewarding reminder of why I value the PostgreSQL community so much. It was delightful to reconnect with familiar faces, meet new people, and finally put some faces to names for the first time. One of the best parts of the day was the sense that this community is larger than any one employer or project. It is built on shared curiosity, shared responsibility, and a willingness to help one another learn. I’m honored to have been able to share my own thoughts in my Disaster Recovery talk as well.

The keynote, Michael Stonebraker’s “Where Did Postgres Come From?”, was a standout for me. I especially appreciated the history of Postgres and the years before Postgres, during the Ingres era. It was striking to hear how the project could have ended up as just another academic system, yet instead grew into something enduring because people outside of UC Berkeley took ownership of it and built a broader community around it. That story felt like a good reminder that open source succeeds not only through technical merit, but through stewardship and continuity.

I also enjoyed Brian Brennglass’s talk, “Managing and Observing Locks.” His demos made an intimidating topic much easier to follow, and I found the practical framing especially useful. Shree Vidhya Sampath’s session on leveraging Patroni’s synchronous replication while running PostgreSQL on Kubernetes was another highlight. I appreciated the clear discussion of election behavior, synchronous replication, and failover scenarios, including failure modes I had not experimented with myself.

Robert Haas’ “pg_plan_advice: Plan Stability and User Planner Control for PostgreSQL?” was impressive in his attention to detail, especially the way he tested edge cases that people might not think to check. Bruce Momjian’s “What’s Missing in Postgres?” was also thought-provoking because it framed missing features not as oversights, but often as deliberate choices shaped by the needs of the broader community. Ryan Booz’s “Mastering P

[...]

All Your GUCs in a Row: deadlock_timeout
Posted by Christophe Pettus in pgExperts on 2026-06-10 at 01:00
PostgreSQL's `deadlock_timeout` controls how often deadlocks are searched for, not how long a deadlock will be tolerated.

Contributions for week 22, 2026
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-06-09 at 08:45

The Prague PosgreSQL User Group met on June 1, 2026, organized by Gülçin Yıldırım Jelínek and Mayur B.

Speaker:

  • Laurenz Albe
  • Josef Šimánek
  • Ants Aasma

PGDay France 2026 took place from June 3-4

Organizers:

  • Jean-Paul Argudo
  • Jean-Christophe Arnu
  • Sylvain Beorchia
  • Damien Clochard
  • Matt Cornillon
  • Flavio Gurgel
  • Yohann Martin
  • Xavier Simon
  • Anaïs Oberto

Talk selection Committee:

  • Yves Colin
  • Bertrand Drouvot
  • Naeva Mallet
  • Helene Nguyen

Speaker:

  • Philippe Viegas
  • Jean-Christophe Arnu
  • Damien Clochard
  • Matt Cornillon
  • Julien Acroute
  • Wilfried Roset
  • Frédéric Delacourt
  • Haritabh Gupta
  • Luigi Nardi
  • Franck Pachot
  • Vincent Mercier

Lightning Talks:

  • Cédric Duprez
  • Etienne Bersac
  • Thibaud Madelaine
  • Sébastien Delobel
  • Alain Lesage

PG DATA 2026 took place on June 4-5 2026.

Organizers:

  • Carlos Aranibar
  • Hettie Dombrovskaya
  • Pat Wright
  • Ellyne Phneah

Talk Selection Team:

  • Dian Fay (non voting chair)
  • Gülçin Yıldırım Jelínek
  • Jay Miller
  • Andrew Atkinson
  • Derk van Veen

CoC Committee:

  • Laetitia Avrot
  • Umair Shahid
  • Jimmy Angelakos

Trainings:

  • Andrew Atkinson
  • Lætitia Avrot
  • Shaun Thomas

Speaker:

  • Robert Haas
  • Radim Marek
  • Umair Shahid
  • Sam Wilson
  • Hajira Sultana
  • Greg Potter
  • Gleb Otochkin
  • Nida Fatima
  • Sami Imseih
  • Chirag Dave
  • Steve Zelaznik
  • Henrietta Dombrovskaya
  • Pavlo Golub
  • Sukhpreet Kaur Bedi
  • Nazneen Jafri
  • Ryan Booz
  • Denis Magda
  • Jimmy Angelakos
  • Paul Jungwirth
  • Ellyne Phneah
  • Apoorv Garg
  • Shaun Thomas
  • Kellyn Gorman
  • Egor Tarasenko
  • Devrim Gunduz
  • Dian Fay
  • Lukas Fittl
  • Pat Wright
  • Alfredo Rodriguez
  • Naresh Reddy Regalla
  • Varun Dhawan
  • Wagner Bianchi

Lightning Talk Speaker:

  • Anna Bailliekova
  • Pavlo Golub
  • Arushi Malhot
[...]

PGConf.dev 2026 in Vancouver
Posted by Christoph Berg in Cybertec on 2026-06-09 at 04:00

The old Postgres Conferences always sounded interesting, but the conference being in Ottawa in Canada and me being in Europe, I've always dismissed them as "too far away" and never bothered going.

Then the organizing team changed and the conference moved to Vancouver for 2024. That's even further away. 2025 in Montreal was a bit closer again, but…

At the October 2025 PGConf.EU conference in Riga, everyone was again excited about the upcoming PGConf.dev 2026 conference. Melanie Plageman, with her organizer hat on, told me "you should definitely come".

So, I finally signed up to join the legendary PostgreSQL developers conference. It was taking place in Vancouver again, and while I had ignored that another extra incentive in 2024, I have family living in Vancouver, so it would be nice to see my sister-in-law's family again.

Pavlo, Ants and I had coordinated travel so we would be on the same plane from Frankfurt to Vancouver. The conference started on Tuesday but we were already going on Sunday so we would have some time to accommodate before. The weird thing about flying west is that time isn't passing, we basically boarded at 10 am and nine hours "later" got off the plane at 10 am again, so we had a full Sunday to start exploring the town. But since we were tired, we were at the hotel at around 5 pm and I slept from 7 until 4 the next morning. Monday was spent going around Stanley Park on rented bikes, where we met the first other attendees.

Tuesday

Tuesday was the first conference day, filled with community discussion sessions. New to me, the conference had organized breakfast for all attendees, so everyone was coming in a bit earlier and we got the hallway track going. This is frankly the most interesting part of any conference to me, talking to old friends, meeting new faces and connecting then to names already known, and exchanging ideas about PostgreSQL and the world. After the opening, Devrim and I had a slot scheduled for making PostgreSQL ecosystem packaging (more) visible where

[...]

All Your GUCs in a Row: DateStyle
Posted by Christophe Pettus in pgExperts on 2026-06-09 at 01:00
PostgreSQL's DateStyle parameter does two unrelated things at once, which explains why it confuses everyone.

My Three Top PostgeSQL 19 Features
Posted by Stefanie Janine on 2026-06-08 at 22:00

PostgeSQL 19 beta 1 has been released on 2026-06-04.

The release is planned for September 2026, though it’s time to go through the new features and changes.

My Top Three Features

All three features below are cool and great developments from the authors of the patches that implemented them. But there are a lot of new cool features and extesnions to exisiting features done by a lot of people.

My thanks go out to all the people who made PostgreSQL 19 possible.

For all others there is still the opportunity to be part of that people, your time is now to test the current and comming beta and release candidates of PostgreSQL 19. And please report bugs you may find.
That way you help all users having a stable release version ready to use in production.

INSERT

The INSERT became a new conflict action: It can now return a SELECT for conflicts.

Previously it already hat the options DO NOTHING and DO UPDATE, the first one did exactly what it was named, doing nothing, the second on offered to update the already existing columns.

The SELECT gives a complete new set of possibilities to handle existing data in an INSERT statement.

REPACK

Previously one needed an extension, pg_repack, but repack is now a command directly availabe in PostgeSQL 19.

Not only is it now a command, it also supports the parameter CONCURRENTLY. That way repack does not affect current database sessions.

And you can pass an index name of an existing index to sort the repacked table after an index. When you have defined the sortorder with CLUSTER and you do not pass an index name, the sortorder is done after the index specified in CLUSTER.

That does obviously not solve the problem of having the table data always physically sorted, but at least with REPACK as regular maintenance job, the data is mostly sorted.

SQL/PGQ

Graph Query Language (GQL) is a standardized query language for property graphs.

SQL/PGQ is the SQL standard extension to add the Graph Query Language to relatianonal datab

[...]

pg_background 2.0: Run SQL in the Background, Now Cleaner, Safer, and Ready for PostgreSQL 19
Posted by Vibhor Kumar on 2026-06-08 at 20:43

Every PostgreSQL developer eventually reaches the same architectural boundary, although the boundary usually appears as an ordinary product request rather than a database design problem. An application transaction needs to complete one business operation, but the surrounding platform also needs to write an audit record, launch a slow report, refresh a cache, fire a notification, or start some enrichment logic that should not delay the user. The first version of the application usually places that extra work inside the same transaction because that approach is simple and convenient. The problem appears later, when a rollback removes diagnostic information, a slow report increases API latency, or a user request begins carrying the weight of every downstream process that the business has attached to it.

PostgreSQL is excellent at transactional consistency because it ensures that related changes succeed or fail together. That behavior is exactly what you want when an order, payment, inventory adjustment, or account update must remain correct. However, there are real-world cases where the triggering transaction and the follow-on work should not share the same fate. An audit record should survive a rollback, a notification should not hold an HTTP request open, and an analytical report should not force a user to watch a spinner while PostgreSQL scans millions of rows.

PostgreSQL does not provide Oracle-style autonomous transactions as a built-in feature, so teams often create their own patterns around this gap. Some teams use dblink loopbacks to force work through another database connection, while other teams use LISTEN and NOTIFY with external workers, polling tables, cron jobs, or message queues. These approaches can work, and larger platforms may still need full orchestration layers when the workflow spans many services. However, when the work is fundamentally SQL that should run inside PostgreSQL, the extra infrastructure can feel like a small bridge built to cross a puddle.

pg_background addres

[...]

How the Other Half Counts
Posted by Christophe Pettus in pgExperts on 2026-06-08 at 15:00
PostgreSQL's query planner gathers statistics one way; Oracle, Db2, MySQL, SQLite, DuckDB, and Snowflake each chose differently.

All Your GUCs in a Row: data_sync_retry
Posted by Christophe Pettus in pgExperts on 2026-06-08 at 01:00
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 assu…

pgsql_tweaks Version 1.0.3 Released
Posted by Stefanie Janine Stölting on 2026-06-07 at 22:00
  1. pgsql_tweaks is a bundle of functions and views for PostgreSQL
  2. Changes In The pgsql_tweaks 1.0.3 Release

pgsql_tweaks is a bundle of functions and views for PostgreSQL

The source code is available on Codeberg.

The extension is also available on PGXN.

The extension is also availabe through the PostgreSQL rpm packages.

Changes In The pgsql_tweaks 1.0.3 Release

This release has been tested against PostgeSQL 19 beta 1 which was released on June 4 2026.
All tests against this new have been successfully passed.

PostgreSQL 13 has been removed from the supported versions as it went out of support on November 13 2025.

In addition the schema description in the function get_markdown_doku_by_schema is now done with a COALESCE to avoid concatenation wiht a NULL value and returning NULL as a result.

All Your GUCs in a Row: data_directory_mode
Posted by Christophe Pettus in pgExperts on 2026-06-07 at 01:00
PostgreSQL 11 lets you create a data directory with group read access (0750) instead of owner-only (0700), enabling unprivileged backup processes to copy files…

All Your GUCs in a Row: data_directory
Posted by Christophe Pettus in pgExperts on 2026-06-06 at 00:13
PostgreSQL solves a bootstrapping puzzle with `data_directory`: how to find the config file before knowing where the data lives.

Beta Testing PostgreSQL With Docker
Posted by Andrew Atkinson on 2026-06-05 at 20:15

The Postgres community values feedback from testing of Beta releases, and with Docker it’s been easier to get pre-release versions up and running.

With the recent announcement of PostgreSQL 19 Beta 1, let’s get that running and test some of the new capabilities.

Pre-Release Versions of Postgres with Docker

First, you’ll need to install Docker for your OS! Grab the version needed for your OS and processor architecture, for example ARM or AMD/Intel/x86.

On MacOS run uname -m or sw_vers in your Terminal to learn more about your hardware details.

For Windows check Install Docker Desktop on Windows

Building and Running

Official Postgres images for Docker Postgres are limited to fully released versions.

Fortunately @yosifkit created a PR to add 19 Beta 1 (merged by @tianon) with instructions for how to use docker buildx to build pre-release versions.

This command downloads and builds postgres:19beta1-trixie: 

docker buildx build -t postgres:19beta1-trixie \
    'https://github.com/infosiftr/postgres.git#19-rc:19/trixie'

With that built, I could invoke docker run with postgres:19beta1-trixie. I named mine pg19.

I also passed the env vars below based on how I run other Docker Postgres containers (these options may not be necessary).

The final command: 

docker run \
--name pg19 \
--env POSTGRES_USER=postgres \
--env POSTGRES_PASSWORD=postgres \
--detach postgres:19beta1-trixie

To check if it’s running, I run docker ps -a. For logs I’d run: docker logs -f postgres:19beta1-trixie.

Connect via psql

The container is running and the logs have what we want: “database system is ready to accept connections”.

Let’s connect to the postgres database using psql on the container: 

docker container exec -it pg19 psql -U postgres

We should see output like showing version 19: 

psql (19beta1 (Debian 19~beta1-1.pgdg13+1))
Type "help" for help.

New Feature Testing in 19

Great. Let’s try out some things in 19.

19 Added a new system view for che

[...]

Acknowledged Individuals in the PostgreSQL Release Notes: 2026 Edition
Posted by Mark Wong on 2026-06-05 at 16:36

I shared a chart, in 2022, showing where PostgreSQL contributor gifts are mailed to.  Here's an updated chart (click to zoom in.)

To quickly recap: the PostgreSQL community has been sending gifts to those who contribute directly to a new major release since version 12 came out.  There has now been 6 releases since then and version 19 is slated to be released this fall.

This chart can be construed as a gross indication of where code, testers, reviewers, bug reports, and documentation are coming from.  Thus it is interesting to see things like which countries have the most people, have been growing, or even to just see how many countries are involved with PostgreSQL.

But it's not an exact measure because this is based on the number of people who claim their gift.  Only about half the people in the release notes claim their gift.  It's not very easy to get in touch with everyone.  If you suspect you might be in the release notes or can help someone claim their gift, please take a look at the release notes (links can be found in the documentation or on the community wiki) and reach out to us by e-mail at contributor-gifts <at> postgresql.org to confirm.

Looking Forward to Postgres 19: Query Hints
Posted by Shaun Thomas in pgEdge on 2026-06-05 at 12:02

Well, the world has officially ended. Peter Venkman from Ghostbusters was right all along, and we'll soon be experiencing "human sacrifice, dogs and cats living together, mass hysteria!" Pack it in everybody; we had a great run. The feature freeze of Postgres 19 includes the one feature many claimed would never see the light of day: query hints. I guess "never say never" is pretty good advice.OK, so they're not technically called hints. The Postgres community would never be so pedestrian. Instead, Postgres 19 introduces two new contrib modules: pg_plan_advice and pg_stash_advice. It's "plan advice" you see. Totally different thing.An occasion this monumental deserves a bit more fanfare than simply describing the feature. So let's begin with a walk through one of the longest-running arguments in Postgres history.

A Brief History of "Never"

The Postgres community's position on query hints has been, shall we say, firm. The official wiki page on the subject states it plainly:"We are not interested in implementing hints in the exact ways they are commonly implemented on other databases. Proposals based on "because they've got them" will not be welcomed."Fair enough. The wiki goes on to list six solid reasons hints are problematic:
  • They create maintenance nightmares.
  • They break on upgrades.
  • They discourage root-cause analysis.
  • They scale poorly.
  • The optimizer is usually smarter than you think.
  • They actually
  • planner improvements because users stop reporting bugs.
Yeah, that sounds about right. And for years, that was the end of the discussion. Postgres doesn't do hints. Go fix your statistics. Next topic, please.But behind the scenes, the debate was never quite so settled. Back in late 2010, a legendary thread erupted on the pgsql-performance mailing list that raged on for several months and captured nearly every available sentiment. It started innocuously enough as a complaint about slow queries, veered through Oracle comparisons, and somehow spiraled into a full-blo[...]

All Your GUCs in a Row: data_checksums
Posted by Christophe Pettus in pgExperts on 2026-06-05 at 01:00
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, e…

A Reviewer Was Born
Posted by Lætitia AVROT on 2026-06-05 at 00:00
A friend of mine, Lucas Draescher, submitted his first patch to PostgreSQL back in March. It fixes a file descriptor leak when using io_method=io_uring. The patch is clean, well-motivated, and on its third revision. It has been sitting in the commitfest for two months with zero reviewers. This is not unusual. This is the norm. The PostgreSQL project runs on volunteer time. Committers are brilliant, but there are not many of them and the patch queue is long.

How to test PostgreSQL 19 beta in your Kubernetes cluster
Posted by Floor Drees in CloudNativePG on 2026-06-05 at 00:00
Participate in the PostgreSQL 19 beta program using Kubernetes and our CloudNativePG operator

File Descriptors: The OS Limit That Takes Down PostgreSQL
Posted by warda bibi in Stormatics on 2026-06-04 at 11:12

Most PostgreSQL outages that trace back to file descriptor exhaustion get misread as a database problem. The failure is one layer down: the kernel runs out of file descriptors and PostgreSQL takes the hit. This post covers how that happens under high connection counts, how to read the log sequence when it does, and how to fix it.

What are file descriptors and why PostgreSQL burns through them

In Linux, the kernel represents almost everything as a file descriptor:  TCP sockets, open table files, index files, WAL segments, temp files for sorts and joins, log files. Every open() or accept() call increments a counter. The kernel enforces a system-wide ceiling called fs.file-max. When total FD usage across all processes on the machine hits that ceiling, every new open() fails; regardless of which process is asking.

There’s also a second, separate limit called the per-process ceiling (RLIMIT_NOFILE, controlled by ulimit -n), which caps how many FDs a single process can hold. Either limit can produce the “out of file descriptors” log message or a single backend hitting its per-process ulimit. Both need to be checked during the diagnosis.

PostgreSQL is process-based. Each client connection spawns its own OS process. Each backend holds FDs for its client socket, the table and index files it’s accessing (managed through PostgreSQL’s internal VFD system, capped by max_files_per_process, default 1,000), WAL segments, and any temp files. An idle backend holds 10–15 FDs. An active write backend touching multiple tables with indexes can hold 50–200 or more.

The theoretical worst case is max_connections x max_files_per_process. In practice you won’t hit that ceiling, but even a fraction of it is dangerous when thousands of connections are open at once.

How exhaustion happens

The failure typically follows the same pattern. max_connections is set high, sometimes 10,000 or more, and the application opens connections freely without a pooler. Because each c

[...]

Does pgBackRest work with pg_tde?
Posted by Stefan Fercot in Data Egret on 2026-06-04 at 07:10

Percona Transparent Data Encryption for PostgreSQL (pg_tde) is an open-source PostgreSQL extension that provides Transparent Data Encryption (TDE) to protect data at rest. pg_tde ensures that data stored on disk is encrypted and cannot be read without the proper encryption keys, even if someone gains access to the physical storage media.

A few months ago, Percona published a blog post describing how pgBackRest can be used with encrypted data, although not all features are supported. In that example, they pass decrypted WAL files to the pgBackRest archiving command and state that asynchronous archiving is not supported because (1) it would copy encrypted WAL segments and (2) the restore_command would attempt to re-encrypt the archived WAL files.

Hallway-track discussions at conferences about this limitation gave me the idea to test it myself, as I suspected that pgBackRest could handle encrypted WAL segments transparently. Let’s take a closer look.

Install PostgreSQL and pg_tde

First of all, I’m going to install PostgreSQL and the pg_tde extension on a Debian 12 test server. As pg_tde currently requires a specific PostgreSQL patch to work, the extension is bundled as a component of Percona Server for PostgreSQL. 

sudo apt-get install -y wget gnupg2 curl lsb-release
sudo wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
sudo apt-get update
sudo percona-release setup ppg-18
sudo apt install percona-postgresql-18
sudo apt-get install -y percona-pg-tde18

There have been many recent discussions about joining efforts to develop a TDE implementation directly in PostgreSQL core, especially during PGConf.dev in Vancouver last month. Until that work is completed, it may be worthwhile to extend PostgreSQL’s capabilities so that extensions like this can run without requiring a patched PostgreSQL fork.

Next, we need to load the library and restart PostgreSQL on our test server: 

ALTER SYSTEM SET shared_preload_librarie
[...]

All Your GUCs in a Row: cursor_tuple_fraction
Posted by Christophe Pettus in pgExperts on 2026-06-04 at 01:00
The planner assumes cursors fetch only 10% of results by default. If you're actually reading them all, that fast-start bias could be killing your performance.

pg_clickhouse 0.3.1: Now With More C
Posted by David Wheeler on 2026-06-03 at 20:13

Hello listeners!

Yesterday, with little fanfare (yay 🎉) we pushed out a minor release to pg_clickhouse, the interface for querying ClickHouse from Postgres. As with previous minor releases, yesterday’s v0.3.0 release requires no reload, restart, or ALTER EXTENSION UPDATE, just reload your session when you’re ready and you’re good to go.

But don’t let the minor version increment deceive you: we made a significant change to pg_clickhouse in this version. What change, you ask? Here it is:

We replaced the clickhouse-cpp library powering the binary driver with the new clickhouse-c library written by my colleague Philip Dubé (a.k.a., serprex). This header-only client library provides a number of substantial benefits vs. the clickhouse-cpp library we previously vendored:

  • Eliminates incompatibility between C++ raise/throw & RAII and Postgres PG_TRY & setjmp/longjmp. The result is much more stable code paths with susceptibility to crashes.
  • Allows us to strictly use Postgres memory contexts, rather than having to deal with both Postgres and C++ allocation patterns, thanks to the library’s support for specifying the memory allocation functions to use.
  • Eliminates the overhead of vendored code, notably absl and cityhash. It does now require liblz4 and libzstd packages, in addition to the previously-required libcurl, uuid, and libssl, but this pattern makes it far more friendly to packager.
  • Far faster compile times and resulting binary. On my M4 MacBook Pro, compiling, installing, and running all the tests now takes around 2 seconds! Meanwhile, the binary size has dropped from 1.8 MB to around 400 KB; on x8664 Linux it went from 4.9 MB to 1.4 MB!

Big change under the hood! Plus a bug fix to properly convert UInt16 values to int32 instead of int16. This is a good one. Get it from the usual suspects:

[...]

Handling graphs with SQL/PGQ in PostgreSQL
Posted by Hans-Juergen Schoenig in Cybertec on 2026-06-03 at 06:51

Starting with version 19 of PostgreSQL users will be able to enjoy something exceptionally useful which will help developers to build even more powerful applications even more quickly. SQL/PGQ — the ISO/IEC 9075-16 (2023) syntax for querying graphs that live in regular relational tables - will be available. This series of posts will explain how this new functionality works and how it can be used to leverage the power of PostgreSQL 19 and beyond.


Your First Graph Query in PostgreSQL 19

The addition introduces two SQL constructs: Namely CREATE PROPERTY GRAPHand GRAPH_TABLE. Let us take a look at the definition of the property graph: 

friends=# \h CREATE PROPERTY GRAPH
Command:     CREATE PROPERTY GRAPH
Description: define a new SQL-property graph
Syntax:
CREATE [ TEMP | TEMPORARY ] PROPERTY GRAPH name
    [ {VERTEX|NODE} TABLES ( vertex_table_definition [, ...] ) ]
    [ {EDGE|RELATIONSHIP} TABLES ( edge_table_definition [, ...] ) ]

where vertex_table_definition is:

    vertex_table_name [ AS alias ] 
[ KEY ( column_name [, ...] ) ] 
[ element_table_label_and_properties ]

and edge_table_definition is:

    edge_table_name [ AS alias ] [ KEY ( column_name [, ...] ) ]
        SOURCE [ KEY ( column_name [, ...] ) 
REFERENCES ] source_table [ ( column_name [, ...] ) ]
        DESTINATION [ KEY ( column_name [, ...] ) 
REFERENCES ] dest_table [ ( column_name [, ...] ) ]
        [ element_table_label_and_properties ]

and element_table_label_and_properties is either:

    NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] )

or:

   { { LABEL label_name | DEFAULT LABEL } 
[ NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] ) ] } [...]

URL: https://www.postgresql.org/docs/devel/sql-create-property-graph.html

Before we dig into this in more detail we need to understand what the purpose of all of this is: In a relational database things are stored as tables. What CREATE PROPERTY GRAPH does is to defi

[...]

pg_stat_statements: everything it can't
Posted by Radim Marek on 2026-06-03 at 06:45

Part one made the core case: pg_stat_statements counts, it doesn't record. It walked through how the queryid jumble fragments one logical query into many rows, how the first-seen text freezes your per-request tags, and how the averages bury the p99 that actually pages you. All of that was about data the extension has and distorts.

This part is about the rest: the entries it silently throws away, the query text that can vanish all at once, the plans and replicas it never records, and the knobs that bite. It ends where part one started, with the question the whole investigation was really about: is this the query store Postgres is missing, or just the floor you'd build one on?

The table fills up and evicts your tail

pg_stat_statements.max defaults to 5000. It's a hard cap on entries, set when the server starts (changing it needs a restart, because the hash table is sized in shared memory up front). When the 5001st distinct shape arrives, Postgres doesn't grow the table. It evicts, throwing out the least-executed entries to make room:

If more distinct statements than that are observed, information about the least-executed statements is discarded.

On a healthy app with a few hundred steady shapes, 5000 is plenty and you never think about it. But remember the row explosion from part one. An ORM that splinters one query into hundreds of shapes, or a pre-18 app building dynamic IN lists, can chew through thousands of entries an hour. Once that starts, the view becomes a sliding window over recent noise. Your steady, important queries get evicted to make room for thousands of one-offs, then rebuilt with fresh counters and a fresh first-seen text when they run again. The stats you were trusting reset themselves, and the view never says a word about it.

One place does say something. The companion view pg_stat_statements_info has exactly two columns, and both matter: 

SELECT dealloc, stats_reset FROM pg_stat_statements_info;
 dealloc |          stats_reset
---------+-----------------------
[...]

Top posters

Number of posts in the past two months

Top teams

Number of posts in the past two months

Feeds

Planet

  • Policy for being listed on Planet PostgreSQL.
  • Add your blog to Planet PostgreSQL.
  • List of all subscribed blogs.
  • Manage your registration.

Contact

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.