Neues vom PostgreSQL Planet

On 22nd of January 2025, Tom Lane committed patch: Support RN (roman-numeral format) in to_number().   We've long had roman-numeral output support in to_char(), but lacked the reverse conversion. Here it is.

Database VIEWs are powerful tools that often don't get the attention they deserve when building database-driven applications. They make our database work easier in several ways:

“Publishing a book is an amazing experience. Writing a book is very, very hard.” Louis Davidson, Simple Talk Editor (@drsql) At the risk of burying the lede… “Introduction to PostgreSQL for the data professional” was officially published on Monday, February 3, 2025 and is available on Amazon, Barnes and Nobel, and through various Redgate channels. ... Read more

With the postgis_raster extension, it is possible to access gigabytes of raster data from the cloud, without ever downloading the data.

How? The venerable postgis_raster extension (released 13 years ago) already has the critical core support built-in!

Introduction

FOSDEM has long been a key event for the PostgreSQL community, and 2025 was no exception. Every year, PostgreSQL developers, contributors, and users worldwide gather in Brussels for a week packed with talks, meetings, and discussions. Our community has a strong tradition at FOSDEM, with a dedicated developer room, a booth, and numerous side events

The Citus 13.0 release is out and includes PostgreSQL 17.2 support! We know you’ve been waiting, and we’ve been hard at work adding features we believe will take your experience to the next level, focusing on bringing the Postgres 17 exciting improvements to you at distributed scale.

This is translation of my report "Debugging PostgreSQL planner" from PGBootCamp 2024 conference.
You can find repository with source code and another staff here.

In this post we will look at how the PostgreSQL planner works, but on code level (functions and data structures) and how to hack on it's planner.

FOSDEM PGDay 2025

For several years there is a PGDay in Brussels on the Friday before FOSDEM organized by PostgreSQL Europe.

The talks that I attended have been good. Only that it the speakers have not been very diverse.

Originally the PL/pgSQL was very simple language and integration procedural language with SQL was very primitive. Very specific feature of PL/pgSQL is translation of every expression to SQL. Thanks to this translation, the PL/pgSQL is very simple and really fully integrated with SQL engine. Bad side is possibility to write dirty or broken code, that is not detected.

Cover photo by Mayukh Karmakar

An issue I often see folks missing when reviewing query plans, is that all of their scans involve indexes, so they think that the query is likely already as fast (or efficient) as it can be.

If you're migrating from Oracle Database to PostgreSQL, you're likely accustomed to using hints to optimize queries. In Oracle, these are special directives embedded in SQL (like ) that steer the optimizer's execution plan. They can be extremely useful but also introduce complexity and “hint debt” over time. PostgreSQL takes a very different approach to query optimization. Rather than supporting built-in hints, the Postgres community, historically, has emphasized relying on its cost-based…

Introduction When building production-grade applications in Go that interact with PostgreSQL, efficient database connection management is crucial for performance and reliability. While you might start with single connections using the pgx driver, as your application scales, you’ll need a more sophisticated approach to handle multiple concurrent database operations. This is where connection pools, specifically pgx/v5/pgxpool, […]

Some of you have been asking for advice about what to submit to the CFP for POSETTE: An Event for Postgres 2025. So this post aims to give you ideas that might help you submit a talk proposal (or 2, or 3) before the upcoming CFP deadline.

If you’re not yet familiar with this conference, POSETTE: An Event for Postgres 2025 is a free & virtual developer event now in its 4th year, organized by the Postgres team at Microsoft.

While answering support issues on pgBackRest, I regularly see some users falling in the infinite archives retention trap and asking the same question: Why are my old WAL archives not being expired?

This is pretty much always linked to a bad configuration of the repo-retention-archive setting. For example, using --repo1-retention-archive=7 --repo1-retention-diff=7 --repo1-retention-full=1.

I arrived in the beautiful city of Prague on Tuesday evening to take part in Prague PostgreSQL Developer Day (P2D2) for the first time . Here are some impression this wonderful event left me with.

In this post, I would like to discuss the stability of standard Postgres statistics (distinct, MCV, and histogram over a table column) and introduce an idea for one more extension - an alternative to the ANALYZE command.

I have been watching the codification of spatial data types into GeoParquet and now GeoIceberg with some interest, since the work is near and dear to my heart.

Materialized views are widely used in Postgres today. Many of us are working with using connected systems through foreign data wrappers, separate analytics systems like data warehouses, and merging data from different locations with Postgres queries. Materialized views let you precompile a query or partial table, for both local and remote data. Materialized views are static and have to be refreshed.

One of the things that can be really important for using materialized views efficiently is indexing.

Backups are crucial for any mission-critical application as they protect against unforeseen disasters. Regular backups help minimize the Recovery Point Objective (RPO), allowing systems to recover quickly with minimal data loss. However, it's equally important to store backups safely. If backups are kept in the same location as the primary site and something goes wrong, you may have no way to recover, leading to complete data loss.

Backups are crucial for any mission-critical application as they protect against unforeseen disasters. Regular backups help minimize the Recovery Point Objective (RPO), allowing systems to recover quickly with minimal data loss. However, it's equally important to store backups safely. If backups are kept in the same location as the primary site and something goes wrong, you may have no way to recover, leading to complete data loss.