PGConf.Russia 2025

В рамках процесса импортозамещения мы столкнулись с необходимостью поиска надежной альтернативы Oracle. СУБД PostgreSQL рассматривалась как основной кандидат на замену, однако в ходе исследования «ванильная» версия выявила ряд критических ограничений, мешающих успешному переходу.

Эти проблемы касались поддержки автономных транзакций, пакетных переменных и ряда других особенностей. В чём особенность pg_settings? Почему нам необходимы именно автономные транзакции и причём тут HOLD-курсоры? Это и многое другое мы расскажем в нашем докладе, а также поделимся своим опытом внедрения Postgres Pro Enterprise.

Сейчас СУБД — неотъемлемая часть любой информационной системы и обработка запросов напрямую влияет на её производительность. 

В прошлом году был сделан доклад с примерами неоптимальных запросов и способами их оптимизации. Тема оказалась востребованной, есть материал для дальнейшего обсуждения. 

Во второй части рассмотрим использование расширенной статистики по вычисляемому столбцу, постраничную обработку и примеры оптимизации запросов из мира 1C.

Всем известно, что для быстрого обновления PostgreSQL нужно использовать инструмент pg_upgrade. Однако даже в этом случае бывают ситуации, когда невозможно уложиться в какое-то нормальное время обновления. В нашем случае, чтобы выполнить обновление в СУБД PostgreSQL, которое содержит 350 тыс. таблиц, пришлось либо ждать 3 с половиной часа, либо найти другой способ обновления. Мы немного покопались в исходниках утилиты pg_upgrade и нашли вариант, когда процесс обновления можно ускорить в несколько раз. Об этом способе мы вам и расскажем.

Внесение изменений в таблицы под «боевой» нагрузкой — это всегда нетривиальная задача. Например, если нужно сменить тип колонки (int —>bigint, timestamp —> timestamptz) или переместить таблицу в другой tablespace, не потеряв изменения, которые происходили во время переливки данных.

А если таких таблиц сотни? С pg-transparent-alter-table это больше не проблема, и такие задачи решаются одной простой командой: $ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Возможности:

— можно указать любое количество команд alter table за раз; 

— можно менять партицированные таблицы, поддерживается старый механизм через наследование, новое декларативное партицирование, многоуровневое партицирование; 

— можно прервать выполнение на любой стадии и продолжить позже, не теряя прогресс предыдущих стадий;

— можно в любой момент передумать, остановить выполнение, выполнить "pg_tat --clean" и вернуться к первоначальному состоянию; 

— есть кастомная команда смены порядка колонок; 

— поддержка версий PostgreSQL 11–17.

За более чем 5 лет существования (раньше назывался transparent-alter-type) проект стал надежным инструментом, который активно используется в продакшене. Хочу поделиться опытом и рассказать про его возможности.