PGConf.Russia 2025

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.

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.

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.