Neues vom PostgreSQL Planet

Introduction

Running ANALYZE (either explicitly or via auto-analyze) is very important in order to have uptodate data statistics for the Postgres query planner. In particular after in-place upgrades via pg_upgrade, ANALYZE needs to be run in order to have any query statistics at all. As ANALYZE samples only parts of the blocks in a table its I/O pattern looks more like random access than sequential read.

Let me present another “first patch” idea, related to a runtime stats on access to files storing data. Having this kind of information would be very valuable on instances with many files (which can happen for many reasons).

This is a very different area than the patch idea, which was about an extension. The runtime stats are at the core of the system, and so is the interaction with the file systems. But it’s still fairly isolated, and thus suitable for new contributors.

CloudNativePG is an open-source operator designed to manage PostgreSQL workloads on any supported Kubernetes cluster running in private, public, hybrid, or multi-cloud environments. CloudNativePG adheres to DevOps principles and concepts such as declarative configuration and immutable infrastructure.

The post Deploying Your First PostgreSQL Clusters on Kubernetes with Cloud Native Postgres appeared first on Stormatics.

In this article, I’ll explore how Kubernetes and CloudNativePG can be leveraged to streamline the testing of PostgreSQL patches, especially during a Commitfest. By automating the creation of PostgreSQL container images from any public Git repository, developers and reviewers can quickly and efficiently test patches within a Kubernetes environment. This approach not only saves time but also enhances the reliability of patches before integration into the main codebase.

In this introduction, we will explore the concept of VACUUM in PostgreSQL, its importance, and best practices for implementing effective vacuuming strategies to ensure your database remains efficient, performant, and reliable. Before we dive into strategies, problem detection and so on, it is important to understand why VACUUM is needed in the first place.

I wrote recently about the performance of PostgreSQL when compiled with different compilers and optimization levels. Another dimension in that evaluation is link-time optimization (LTO).

LTO allows the compiler to perform optimizations across source-file boundaries (more correctly, compilation unit boundaries).

Join us for the Postgres Happy Hour in Vienna on September 18th!

• Greg Sabino Mullane analyzed a year’s worth of pgsql-hackers traffic, deciphered the language used on that mailing list, and compiled a jargon file for newcomers: crunchydata.com/blog/understanding-the-postgres-hackers-mailing-list.

These are my least favorite mysteries to resolve. I hate mysteries when it comes to performance problems. A performance mystery means I do not know how to make it work faster! However, I love solving mysteries—except when presented with a “sometimes it is slow” case.

Redgate's State of the Database Landscape Survey is back again in 2024 and ready for your feedback! The 2023 survey gathered insights from nearly 4,000 data professionals about evolving database complexities and skill demands. The 2024 survey will focus on learning, AI, cloud, and security. Participate for insights and a chance to win Amazon vouchers.

PostgreSQL Person of the Week Interview with Amul Sul: I am Amul Sul, and I grew up and completed my university studies in Mumbai. I did my master’s in computer application from VJTI, Mumbai. In 2012, NTT DATA brought me on board through campus placement. For three years, I dived deep into PostgreSQL, working on NTT DATA’s internal PostgreSQL project.

I have been meaning to support common DDLs (Data Definition Language) for pg_easy_replicate for quite some time now and I am super stoked that it is now finally out. This new capability addresses one of the limitations of PostgreSQL’s native logical replication, bringing more flexibility to database migrations and replication through pg_easy_replicate. What is pg_easy_replicate? For those new to the project, pg_easy_replicate is a CLI orchestrator tool that simplifies the process of setting up and managing logical replication between PostgreSQL databases.

I have been meaning to support common DDLs (Data Definition Language) for pg_easy_replicate for quite some time now and I am super stoked that it is now finally out. This new capability addresses one of the limitations of PostgreSQL’s native logical replication, bringing more flexibility to database migrations and replication through pg_easy_replicate. What is pg_easy_replicate? For those new to the project, pg_easy_replicate is a CLI orchestrator tool that simplifies the process of setting up and managing logical replication between PostgreSQL databases.

I’ve decided to experiment a little bit and do regular “office hours.” I’ll be available to chat about almost anything related to Postgres. It might be a technical discussion about a patch you’re working on, or a topic about the community etc. This is not an entirely new thing. I’ve been telling people to just ping me if they want to discuss something off-list, or have a call and chat about it.

Welcome to Part 6 of our series exploring the exciting new features anticipated in the official PostgreSQL 17 release. In this series, we delve into newly added features and discuss how they can benefit database developers and migration engineers transitioning to PostgreSQL 17 in future.

In case you missed the earlier parts:

The annual PgUS membership meeting was prepared and conducted by: * Stacey Haysler (President) * Mark Wong (Treasurer & Expo Committee) * Michael Brewer (Secretary) * Jonathan S.

The Postgres hackers mailing list (pgsql-hackers@postgresql.org) is an invaluable resource for anyone wanting to contribute to the PostgreSQL code. The Postgres project does not use PRs (pull requests) or GitHub issues. So if you want to contribute an idea, or help with code reviews, the hackers mailing list is the canonical way to do so.

PostgreSQL is a powerful and open-source relational database system known for its reliability, flexibility, and advanced features. It handles complex queries, ensures data integrity, and can be extended to meet various needs, making it a popular choice for many applications. However, as your data grows and the number of transactions increases, scaling PostgreSQL can be challenging.

On August 8th and August 15th, the first two “PostgreSQL Hacking Workshops” took place. Robert Haas previously asked on Discord for topics, and the highest vote was for “PostgreSQL Optimizer Methodology”. The invited attendees are expected to watch the video before, and bring questions to the workshop.

Crunchy Data is pleased to announce a new open source pgMonitor Extension. Crunchy Data has worked on a pgMonitor tool for several years as part of our Kubernetes and self-managed Postgres deployments and recently we’ve added an extension to the tool set.

Two primary scenarios motivated the creation of the pgMonitor extension :