Talks

Many developers often face performance issues in the systems they develop. One common solution for optimizing slow business processes is parallelization. But what do you do if the bottleneck is the data insertion into the database, which needs to maintain atomicity?

In this talk, I’ll explain how to speed up data insertion by parallelizing the process in Spring, while ensuring the atomicity of the entire operation. We'll cover batch updates in Spring and PostgreSQL, discuss why updates are heavy operations, and explore ways to speed up the process in the current tech stack. Additionally, I will present other approaches to maintaining atomicity and demonstrate their differences in benchmarks.

This will be useful for practicing engineers.

There are many administrator consoles out there, ranging from the old-school DBeaver to the ubiquitous pgAdmin. However, we decided to create another one. Why?

In this talk, you’ll learn:

• How can a single installation manage tens of thousands of database instances.

• How many users can the console support.

• How can you inventory your infrastructure without losing your sanity.

• How do you integrate into an existing environment without starting from scratch.

• How to build a security model that earns the trust of leading banks and telecom operators.

• How can you get hands-on experience with all of this.

Two years ago, I spoke about data retrieval queries, where the LINQ to DB library offers almost limitless possibilities.

This talk is about data modification operations. LINQ to DB allows you to execute UPDATE + JOIN queries, INSERT FROM SELECT, supports the MERGE operator, row-level locking with SELECT FOR UPDATE, temporary table creation, and features a fast data insertion mechanism.

I will also discuss the linq2db. EntityFrameworkCore project — a solution for those who aren’t ready to leave EF Core but still want the capabilities of LINQ to DB. I’ll share our experience implementing LINQ to DB in a large-scale project.

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.

The issue of slow month-end closing and cost calculation on PostgreSQL has been a long-standing problem. In this talk, we will explore what modern versions of PostgreSQL offer in this regard and answer the question, "Do replicas slow down the master?"

We will also take a look at different types of physical replication and, for dessert, share a recipe for quick and painless month-end closing in 1C without affecting the daily operations of users.

I’ll talk about the challenges you’ll face if you decide to implement a new TableAM. What to choose: Generic XLog or Custom RMGR? Why use a Custom SMGR? How to integrate PostgreSQL allocators into third-party libraries, even if they don't officially support it? What’s missing for a columnar engine (including vectorization and late materialization), and how can we work around those limitations?

In the second part, I’ll dive into the internals of pgpro_tam — a new native table engine for OLAP that supports standard data formats, various SMGRs, and, if needed, third-party schedulers and execution engines, all while adhering to ACID principles. This is designed to achieve the fastest analytics on PostgreSQL (not just plugging in DuckDB).

So much has been said about PostgreSQL as the result of its program code. But Postgres is not just code. It’s the people who create it, develop it, and... leave a piece of themselves through comments.

What stories can we uncover from the comments in PostgreSQL’s code? We’ll discover what the most popular word is, which comments have been in the code since the very first public commit, how the style of communication has evolved with the product, and how we can see the human side behind the lines of code and comments.

In this talk, I will challenge architectural stereotypes about the impossibility of communication with external systems directly from a DBMS. PostgreSQL offers vast communication capabilities; you just need to know which extensions to use.

And when extensions aren't enough, you can create your own. For the Luxms BI project, we needed communication with NATS, so we developed our own extension in Rust. I’ll share the GitHub link and my experience of developing PostgreSQL extensions in Rust during this talk.

In this session, we’ll provide an overview of the features of the pg_probackup3 backup utility. 

The new version has completely rethought the application architecture, introduced several long-awaited features, and added integration possibilities with other applications. We’ll dive into these updates and discuss them in detail during the presentation.

Last year, we introduced built-in fault tolerance support in Postgres Pro Enterprise through BiHA. Our solution allows you to deploy a fault-tolerant Postgres cluster where, in the event of a failure of the primary node, a new primary node (leader) is automatically selected.

However, this brings up the issue of redirecting traffic to the new leader. This can be solved using our Proxima extension or an external TCP proxy server. Both solutions needed to periodically query the BiHA cluster to determine the primary node.

As an alternative, the latest version of BiHA introduced the ability to register custom functions that will be triggered by events such as leader change, node addition/removal, and others. We call this mechanism user callbacks. In this presentation, we’ll explain how the callbacks are implemented and discuss their usage.

A brief presentation on various extensions that can assist with optimization.

In today’s rapidly evolving technology landscape, PostgreSQL has emerged as a popular choice for organizations seeking to leverage the power of open-source databases while maintaining scalability, performance, and flexibility. 

As enterprises migrate from proprietary database systems like Oracle to PostgreSQL, developers face the challenge of adapting existing PL/SQL codebases to PL/pgSQL. Despite the similarities between these two procedural languages, significant differences in their syntax, performance characteristics, and ecosystem features require a thoughtful approach to migration and optimization. 

This session will focus on highlighting the key differences between Oracle’s PL/SQL and PostgreSQL’s PL/pgSQL, providing actionable insights on how to efficiently navigate these differences during migration. A deep dive will be taken into critical areas including compilation methodology, Code Debugging , Exception Handling, work_mem , Bulk Load and more.

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.

Which method of data retrieval in PostgreSQL works faster: several simple SQL queries, ORM tools (Hibernate, jOOQ), or a single query with JSON aggregation? 

In this talk, we will explore several data extraction strategies, compare their performance, and discuss potential pitfalls. We will look at how ORM tools handle one-to-one and one-to-many relationships, the overhead that arises when using JOINs, and why JSON-based retrieval might be the most efficient solution. Real benchmarks, the pros and cons of each approach – all of this will be covered in our research.

In this talk, we will discuss what character encodings and collations are. I will explain the issues that can arise from sorting (COLLATION) in databases and show how these problems can be addressed using the COLLATION PROVIDER = ICU feature in PostgreSQL.

This talk will likely be of interest to network providers who can enhance their cool features by adding something to the syntax to simplify administration, as well as anyone interested in machine learning. We will explore the SQL parsing mechanism, what, where, and how to modify it in order to introduce new syntax constructs. Additionally, I will demonstrate the capabilities of machine learning on tabular data, all within the database, using the new syntax.

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.

For over a year, Postgres Pro has provided extended vacuum statistics, reflecting its operation on individual relations.

We've started receiving observations from production databases of clients that include these statistics. It has been quite successful, and in 2024, we began actively promoting vacuum statistics in PostgreSQL. In this talk, we will review what these statistics can tell us about the complex life of vacuum, using real-world data from live systems.

Greenmask is an open-source utility for database anonymization and synthetic data generation. A common challenge in development is creating test environments that closely resemble production. In this talk, we will explore how to use Greenmask’s features to prepare a test environment with ease. 

We will discuss its architecture, database subsets, types of transformations, the reasons for integrating with the PostgreSQL driver, and porting some pg libraries. Additionally, we will explain how our technology helps businesses solve problems faster, more efficiently, and securely.

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.

Making changes to tables under production load is always a complex task. For example, when you need to change a column type (e.g., from int to bigint or from timestamp to timestamptz), or move a table to a different tablespace without losing any changes that occur during the data migration.

What if you have hundreds of such tables? With pg-transparent-alter-table, this is no longer a problem. These tasks can be solved with a single simple command:
$ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Key features include:

• You can specify any number of alter table commands at once.
• You can modify partitioned tables, supporting both the old inheritance-based partitioning and new declarative partitioning, including multi-level partitioning.
• You can interrupt the process at any stage and continue later without losing progress from previous stages.
• You can change your mind at any time, stop the execution, run "pg_tat --clean," and revert to the original state.
• Custom commands for changing column order.
• PostgreSQL version support: 11-17.

After more than 5 years of existence (previously called transparent-alter-type), the project has become a reliable tool actively used in production. I would like to share my experience and discuss its capabilities.

Data plays a vital role in daily operations for many organizations. Organizations maintain updated data by performing various operations like data cleansing ,importing customer data and other similar operations , sometimes while working with massive data loads is challenging. Both Oracle and PostgreSQL systems have their advantages and challenges while working with bulk data loads. This talk underlines differences which will allow Database Administrators and Developers to tailor their approaches for planning , configuration , and understanding database features and optimizing performance of Data Ingestion. 

• Effective use of Constraints. 
• Role of Autovacuum Process. 
• How to set work_mem ? 
• Using LIMIT / OFFSET in bulk loads. 
• Prepared Statements. 
• UNLOGGED Tables. 
• Temp tables Usage. 
• Parallel Processing. 
• Effectively Updating all the records of a specific Column with a single value. 
• COPY Command. 
• Significance of Partition Table. On Conflict / Do Nothing.

As part of the import substitution process, we encountered the need to find a reliable alternative to Oracle. PostgreSQL was considered the primary candidate for replacement, but during the research, the "vanilla" version revealed a number of critical limitations that hindered a successful transition.

These issues included support for autonomous transactions, batch variables, and several other specifics. What is special about pg_settings? Why do we need autonomous transactions, and how do HOLD cursors relate to this? These and other topics will be discussed in our presentation, where we will also share our experience of implementing Postgres Pro Enterprise.

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.

This presentation examines the challenges of migrating an application system from Oracle to Postgres, based on a real-world project. It provides a detailed discussion on logical replication of data from Postgres to ensure the possibility of reverting back to Oracle while maintaining the functionality of legacy reporting and integration.