PGConf.Russia 2025

The work of a DBA is very multifaceted: backups, version updates, performance issues — there's a long list. But sometimes, due to the workload, we don't give enough attention to innovations that don't directly relate to what we do every day. Such is the case with logical replication.

Of course, each of us has some skills working with this tool, but PostgreSQL is a rapidly evolving database system. Sometimes, we simply need to look around with a fresh perspective to see something new.

My presentation will be based on this approach: we'll start with theory (as always, less theory, more practice) and simple examples, then move on to more complex examples of its use. Special attention will be given to what has changed in modern versions of PostgreSQL.

This presentation will be helpful for those who want to get acquainted with logical replication or refresh their knowledge of this tool.

The focus of the presentation is on the challenges of building an application solution on PostgreSQL, specifically a high-load analytical data warehouse. Using the case of the company EVRAZ, we will demonstrate the impact of applying the Data Vault methodology on PostgreSQL and Greenplum databases for developing a unified production performance system.

We will discuss the difficulties and solutions, showcasing query plans for tasks such as updating directories and handling large objects, along with optimization examples. We will highlight coding nuances, problems related to populating the model, and issues with querying from the model.

This session will be useful for those planning to use or already facing challenges with the Data Vault methodology and performance issues in DWH on the open-source stack. We will compare technical implementation options for the Business Vault model layer, considering the specifics of PostgreSQL and Greenplum.

We will also cover 5 real problems that arise when operating a DWH and their solutions:

1. Transferring Business Vault object assembly logic from PostgreSQL to Greenplum.
2. Slower ETL performance when building the current state of Business Vault in PostgreSQL.
3. Slower Data Lineage construction in PostgreSQL and Greenplum.
4. Slow satellite queries in Greenplum.
5. Slow queries with "IN" or "OR" in the Business Vault layer.

This talk addresses a common issue and touches a bit on application architecture. Temporary tables in database applications are typically used for several purposes. 

Firstly, they are used to store intermediate results when implementing complex data processing algorithms. Secondly, in the case of stored procedures, application servers often place large datasets into temporary tables when they are too large or inconvenient to pass as parameters to stored procedures. 

The handling of temporary tables in different DBMSs is implemented in various ways, which often complicates migration from these systems to Postgres. 

The drawbacks of temporary tables are well-known, which leads to a reasonable desire to replace them, where possible, with other methods that can achieve the same goal. This talk focuses on alternative mechanisms provided by Postgres to solve this problem.

Sometimes, issues arise with the operation of PostgreSQL on Linux. We will define a classification of these scenarios and provide solutions, from simple to complex. Which failures lead to data corruption? Which scenarios are more dangerous than others, and what should be monitored? We will review logging examples from DBM.P Skala-R and analyze debugging scenarios, including OS libraries, Linux kernel, drivers, and kernel modules to identify causes and resolve errors.