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.

Covering all the key changes in PostgreSQL 18 during this talk would be quite a challenge — especially since the code freeze is set to happen just a week after the presentation. However, I’ll focus on what has already been finalized.

There are plenty of exciting updates in performance, monitoring, vacuuming (of course!), and beyond. As always, this talk is based on a series of articles reviewing the commit fests for PostgreSQL 18, published on Postgres Professional’s corporate blog on Habr.

The visibility map in PostgreSQL is an important mechanism for optimizing database performance, accelerating read operations, data cleanup, and indexing. Despite some limitations, such as memory consumption and fragmentation, its use can significantly enhance performance in high-load systems. Effective utilization of the visibility map requires proper configuration and monitoring, which is especially crucial in systems with large data volumes and high transaction concurrency.

Experience Report addressing the manual migration of MS SQL Server Stored Procedures and Table-Valued Functions to PL/pgSQL. We chose a manual migration from T-SQL over using a PostgreSQL Extension with an automated translation. The motivation was that the T-SQL code contains non-trivial business logic for which we wanted idiomatic PL/pgSQL code. 

The T-SQL Code used features like 

• Mix of Stored Procedures and Table-valued Functions

• Table variables, (user-defined) table types 

• Recursive Common Table Expressions 

• Optional parameters 

The migration required

• Adopting naming conventions 

• Renaming parameters and local variables 

• Maping table types 

• Mapping table-valued parameters to arrays 

• Mapping table-valued return types to SETOF record

• Translating between arrays and tables 

In this session we will migrate a chain of dependend functions T-SQL functions to PL/pgSQL. We will work around quirks in both T-SQL functions and PL/pgSQL.