Sammlung von Newsfeeds
Robert Haas: Who Contributed to PostgreSQL Development in 2025?
Here is another annual blog post breaking down code contributions to PostgreSQL itself (not ecosystem projects) by principal author. I have mentioned every year that this methodology has many limitations and fails to capture a lot of important work, and I reiterate that this year as usual. Nonetheless, many people seem to find these statistics helpful, so here they are.
Read more »Frédéric Yhuel: The strange case of the underestimated Merge Join node
This post appeared first on the Dalibo blog.
Brest, France, 19 January 2026
We recently encountered a strange optimizer behaviour, reported by one of our customers:
Customer: “Hi Dalibo, we have a query that is very slow on the first execution after a batch process, and then very fast. We initially suspected a caching effect, but then we noticed that the execution plan was different.”
Robins Tharakan: Turbocharging LISTEN/NOTIFY with 40x Boost
Unless you've built a massive real-time notification system with thousands of distinct channels, it is easy to miss the quadratic performance bottleneck that Postgres used to have in its notification queue. A recent commit fixes that with a spectacular throughput improvement.
Henrietta Dombrovskaya: Illinois Prairie PUG January Edition
We just had the first meetup of 2026, and all I can say is a huge thank you to Ryan Booz and all attendees, both in person and virtual!
I was so happy to see many familiar faces, as well as first-timers. We had great attendance (one of those rare situations when I didn’t order enough pizza :)). Ryan Booz, who, as I previously mentioned, is one of the few out-of-towners who dare to face Chicago winter weather, presented a great talk on configuring Postgres for effective logging and query-optimization analysis.
Dave Page: Introducing pgEdge Load Generator: Realistic PostgreSQL Workload Simulation
Anyone who has worked with PostgreSQL in production environments knows that testing database performance is rarely straightforward. Synthetic benchmarks like pgbench are useful for stress testing, but they don't reflect how real applications behave. Production workloads have peaks and troughs, complex query patterns, and user behaviour that varies throughout the day. This is why I'm pleased to introduce the pgEdge Load Generator.
Robert Haas: Hacking Workshop for February 2026
Avi Vallarapu: Contributions to PostgreSQL by HexaCluster in 2025
Jimmy Angelakos: Announcing the second PostgreSQL Edinburgh meetup
The Lister Learning and Teaching Centre at the University of Edinburgh. Photo by Paul Zanre - COPYRIGHT: PAUL ZANRE PHOTOGRAPHY.
I'm thrilled to announce that the PostgreSQL Edinburgh meetup is back! 🐘
Floor Drees: PostgreSQL Contributor Story: Mark Wong
Pavlo Golub: Stand Up, Mentor! Help Postgres Shine in GSoC 2026!
Google Summer of Code is back for 2026! We’re celebrating the 22nd year of this incredible program that has brought countless talented developers into the open-source world. Please take a moment to review Google’s announcement and familiarize yourself with what makes this year special.
Ian Barwick: PgPedia Week, 2025-12-28
Laurenz Albe: Dealing with integer overflow in sequence-generated primary keys
© Laurenz Albe 2025
Radim Marek: The hidden cost of PostgreSQL arrays
Starting with arrays in PostgreSQL is as simple as declaring a column as integer[], inserting some values, and you are done.
Or building the array on the fly.
Jimmy Angelakos: pg_statviz 0.9 released with new features
Happy New Year! I'm excited to announce release 0.9 of pg_statviz, the minimalist extension and utility pair for time series analysis and visualization of PostgreSQL internal statistics.
This is a significant feature release that expands the scope of analysis to include several new modules and a visualization update:
Esther Minano: Optimizing data throughput for Postgres snapshots with batch size auto-tuning
Floor Drees: Updating CloudNativePG's documentation
Virender Singla: Idle Session Triggers a Transaction Wraparound?
At first glance, the idea that an idle session could lead to a transaction wraparound might seem counterintuitive. Most PostgreSQL users are familiar with how long-running queries or open transactions can cause table bloat and wraparound risks by pinning the xmin horizon, which prevents autovacuum from reclaiming dead tuples and Transaction IDs.

