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.

In PostgreSQL performance testing, benchmarks measure query execution time (latency). To get more reliable results, queries are executed repeatedly, generating a dataset of latency values. Performance is often assessed using standard metrics like the median or mean, but we propose a more advanced approach.

In practice, latency distributions are often multimodal, consisting of multiple underlying distributions with distinct characteristics. In such cases, traditional statistical methods are insufficient, requiring a more detailed analysis of the dataset’s structure.

Our work presents a tool that automatically performs statistical analysis of benchmark results, accounting for dataset-specific features. It detects multimodality, identifies the number and boundaries of dominant modes, and determines key distribution parameters—providing deeper insights into PostgreSQL performance variations.

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.