PGConf.Russia 2025

Доклад описывает проблемы, с которыми мы столкнулись (и решили) в процессе миграции данных очень больших СУБД — с Oracle на Postgres.

Одной из тяжёлых частей такого процесса является пересоздание FK. В процессе разрешения проблем пришлось углубиться в некоторые внутренние особенности процесса создания/валидации внешних ключей. Например, есть ли execution plan у ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY .. ? Можно ли на него повлиять простому смертному? Какие блокировки накладываются при создании/валидации FK? 

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

При нагрузочном тестировании PostgreSQL бенчмарки замеряют время исполнения запроса (latency). Для более объективного результата запрос выполняется большое количество раз — из этого получается некоторый набор latency. Для оценки производительности PostgreSQL на данном запросе можно использовать стандартные методы, такие как медиана или среднее, но мы предлагаем использовать более комплексный подход. Как показала практика, такие выборки часто бывают мультимодальными и состоят из различных распределений с некоторыми параметрами. 

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

Внесение изменений в таблицы под «боевой» нагрузкой — это всегда нетривиальная задача. Например, если нужно сменить тип колонки (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) проект стал надежным инструментом, который активно используется в продакшене. Хочу поделиться опытом и рассказать про его возможности.

Доклад, скорее всего, будет интересен сетевым провайдерам, которые к своим крутым фичам могут добавить что-то в синтаксис, чтоб упростить администрирование, а также всем, кто интересуется машинным обучением. Будет рассмотрен механизм разбора SQL, что, где и как поменять, чтобы внедрить новые синтаксические конструкции. Также продемонстрирую возможности машинного обучения на табличных данных не выходя из базы с использованием нового синтаксиса.