Прошла пятая ежегодная конференция PG BootСamp Russia. В этот раз она проходила в Москве 19 марта 2026 года. 563 оффлайн участника и порядка 1300 онлайн. Первая конференция прошла в 2023 году и дальше проводилась в разных городах. В статье - репортаж с конференции и краткий обзор докладов.
Идею проводить PG BootCamp придумали Михаил Гольдберг и Брюс Момжан
Открывали конференцию члены оргкомитета: PostgreSQL Major Contributor Андрей Бородин (Yandex Cloud) и генеральный директор Тантор Лабс Вадим Яценко
На сцену пригласили Ивана Кузьмина (СКАЛА-Р), который не пропустил ни одной конференции, включая юбилейную этого года. Стабильность и предсказуемость - свойство реляционных баз данных. Ивану хотели дать бесплатный билет на конференцию, но увы, конференция PG BootCamp бесплатна для участников, поэтому Ивану вручили другую награду :-)
По традиции, участников конференции приветствовал Брюс Момжан:
Архив будущего
Первым докладом был доклад Андрея Бородина "Архив будущего". В докладе описывались актуальные проблемы архива WAL.
Андрей отметил удачную идею линий времени (timelines). Бэкап может начатья на одной линии времени, а закончиться на другой. И с такого бэкапа можно будет восстановиться. Такой бэкап будет создан, если реплика (или какая-то реплика до той, с которой берётся бэкап) стала мастером. Такое возможно в случае запланированного переключения (switchover).
Вторая особенность, которая рассматривалась в докладе: перед переключением на нового мастера старый, начинает останавливаться. При остановке выполняет финальную контрольную точку и может это делать долго. Если не дождаться завершения контрольной точки и выполнить promote одной из реплик, то старый мастер придется возвращать в строй утилитой pg_rewind.
Андрей предложил патч https://commitfest.postgresql.org/patch/6177/ , устраняющий проблему одновременной архивации WAL с мастера и реплик, так как используя always, сложно настроить беспроблемную архивацию
При использовании архива WAL процесс startup может использовать restore_command, если этот параметр сконфигурирован. Из-за ошибки с двойной остановкой процесса walreceiver (сигналом SIGTERM), процесс startup может взять WAL-сегмент из архива (сообщение в диагностическом журнале "restored log file from archive"). Процесс startup выполняет restore_command, если walreceiver не может получить журнальные данные. Есть вероятность, что в архив не успеет записаться WAL-сегмент последней линии времени, реплика применит WAL-файл с предыдущей линии времени и останется на ней. Ошибка не позволит реплике работать и такую реплику придется восстанавливать или пересоздавать. В диагностическом логе будут сообщения:
Нумерация линий времени в диагностических сообщениях в десятеричной системе, а в названиях файлов history в шестнадцатеричной. Например, при создании timeline 10 создаётся файл 0000000A.history.
Андрей создал патч, исправляющий проблему.
Также Андрей рассказал об идеях, как можно было бы улучшить работу PostgreSQL. Например, чтобы база данных совмещала все операции массового чтения: резервирование с вакуумированием и сбором статистики. Чтобы за одно чтение все выполнялись все три действия и не нужно было бы повторно читать данные.
Андрей (во втором ряду) слушал доклады на конференции:
Есть ли будущее у генетических и обучаемых методов в оптимизации запросов
После Андрея в основном зале конференции выступила Алёна Рыбакина (Яндекс). Алёна, как никто, детально разбирается в работе планировщика и сделала прекрасный доклад с обзором методов работы планировщика. Алёна сделала детальный обзор методов поиска оптимального порядка соединения таблиц. В докладе также были рассмотрены алгоритмы оптимизации соединений с использованием машинного обучения: SkinnerDB, Neo-TreeCNN, BaoHint+Bandit.
Алёна академически точно описала текущее состояние методов оптимизации соединений наборов данных:
Алёна не только выступает на конференциях, но и пишет статьи для хабра: Путь в коммиттеры PostgreSQL начинается с первого ревью
Старые архитектурные проблемы PostgreSQL и их решение
После Алёны Рыбакиной выступил Вадим Яценко (Тантор Лабс) с докладом о решениях архитектурных проблем PostgreSQL. За две недели до конференции была опубликована статья, поэтому доклад вызвал интерес.
PostgreSQL - универсальная СУБД с большим международным сообществом. Вадим давно работает с базами данных большого размера. В 2017 Вадим делал доклад https://pgconf.ru/talk/1588070 о том, какие особенности встречались при работе с 25 серверами PostgreSQL в 2 центрах обработки данных с суммарным объем хранящихся данных 300ТБ, которые обслуживали систему Платон. В то время был большой секпсис относительно использования PostgreSQL и продвигать его было сложно.
Александр Коротков, один из основателей компании Postgres Professional, после ухода из которой, создал OrioleDB и, в настоящее время, единственный коммитер из России https://www.postgresql.org/developer/committers/ , выделил 10 проблем
Вадим выразил мнение, что шардинг в PostgreSQL для OLTP нагрузки - не рабочая схема. Мне это понравилось, потому, что я такого же мнения об этой технологии, что для PostgreSQL, что для Oracle и в ней больше моды, чем технической составляющей. Специалисты, которые поддерживают реальные системы, не следуют моде, а используют реальные технологии. Я был рад, что не так давно OpenAI поделились описанием архитектуры хранения данных с использованием 50 реплик PostgreSQL https://habr.com/ru/news/988632/
Мне также нравится политика сообщества Postgres Development Group, благодаря которой PostgreSQL не обрастает кучей костылей, а сообщество может позволить себе включать в PostgreSQL только качественные улучшения
Дальше Вадим перешел к описанию тех возможностей, которые Тантор Лабс нашел и стал дорабатывать. Были взяты технологии Alibaba Polar. Не буду описывать то, что было в докладе. Для себя я выделил основные моменты: Polar аналогичен Oracle RAC. Это возможность обслуживать один кластер PostgreSQL нескольким экземплярам. Пишущим является только один экземппляр. Для такой работы нужна кластерная файловая система. Для Oracle RAC это ASM или NFS. В Polar это называется PolarFS. Также я проверил, что на конфигурацию PolarDB (кластер, обcлуживаемый несколькими экземплярами) можно создать конфигурацию-реплику PolarDB, аналогично Oracle Data Guard+RAC. То есть можно иметь две PGDATA в разных центрах обработки данных, каждая из которых, обслуживается своим набором экземпляров. Обычно, покупались две Exadata: одна full или половинка для primary, вторая - четверть или половина для standby и ставились в две стойки (рядом и ли в разных центрах обработки данных компании-владельца). У primary и standby своя конфигурация ASM и свои дисковые группы. И такая конфигурация работает с PolarDB. Alibaba, как и Amazon с Aurora, конечно, разносит storage по своим центрам (геомирроринг), но это оправданно для облачных компаний. Для компаний проще и производительнее разнести две Exadata или xData по своим центрам и связать их (RAC в Exadata или Tantor Polar в xData) физической репликацией.
В Polar один запрос может использовать параллельные процессы на всех экземплярах, точно так же, как и Oracle RAC. Это позволяет обрабатывать запрос, задействуя все вычислительные узлы. В докладе приведен пример TPC-H теста на Tantor xData Gen3, состоящей из 3 вычислительных и 3 узлов хранения на процессорах AMD и системных платах Supermicro. Конфигурация: один мастер и две реплики. На узлах одновременно запускались тесты pg_bench (TPC-B), выдающих 204000 TPS. Одновременно и на тех же узлах запускался TPC-H. Q1 запускался в 128 потоках и выполнился за 11,77 секунд. Q2 - 3,451 секунды. Планировщик GPORCA и параллельное выполнение на всех узлах с динамическим выбором степени параллелизма с ограничением в 128 процессов (MAX_DOP=128).
Технические подробности Tantor Polar описывал Алексей Копытов в следующем же докладе "Разделение compute и storage: архитектурный прорыв для PostgreSQL в облаке". Я выделил для себя следующие момееты: Tantor Polar использует 15 версию PostgreSQL, но ведется перебазирование на 17 версию; Alibaba совсем недавно выложил Alibaba Polar для 17 версии; Добавление, запуск дополнительных экземпляров выполняется динамически, это позволяет без остановки масштабировать нагрузку.
На буткэмпе была фотомашина, которая фотографировала
и печатала фотографию с xData. Можно было сфотографироваться с участниками и участинцами конференции:
Реально работающая машина xData Gen3 стояла неподалёку и выполняла тесты. С ней тоже можно было сфотографироваться:
На выставке я не обратил внимание, а на фотографии обратил: на экране слева выведена страница Платформы Тантор, которая мониторила экземпляры кластеров PostgreSQL на xData.
После обеда был доклад уважаемого члена сообщества, контрибьютора Андрея Лепихова (pgEdge), разработавшего Multimaster https://habr.com/ru/companies/postgrespro/articles/956440/
Андрей живёт в Мадриде и выступал по телемосту. Качество звука было отличное
Валим "слона"
После доклада Андрея шел доклад Кирилла Боровикова (Тензор). Кирилл много лет занимается анализом планов выполнения запросов
Я считаю, что Кирилл лучше всех в мире (да, во всём мире) умеет писать запросы SQL. Я могу оценивать профессионализм, у меня есть справка:
Кирилл Боровиков (@Kilor) опубликовал на хабре 182 статьи https://habr.com/ru/users/Kilor/articles/ По оценке Кирилла, особенности 95% запросов он описал и только 5% запросов представляют какой-нибудь интерес. Это значит, что для 95% запросов программа Saby компании Тензор (встроена в Платформу Тантор) даст рекомендации, как устанить проблемы с запросом и ускорить его выполнение. Тензор это аналог Oracle ADDM Findings для SQL-запросов. Тензор даёт не только простейшие рекомендации типа «создай индекс», но и довольно сложные.
Кирилл дал практические рекомендации. Например, приведение типа numeric к integer (если достаточно точности) снижает в 4 раза объем передаваемых клиенту данных
Больше всего мне понравилось, что Кирилл говорит "пейджинг", а не "пагинация". Также абсолютно правильно сказал, что пейджинг по умолчанию зло, но, если бизнес требует, то иногда можно. По используемым терминам можно легко определить настоящих специалистов от недавно познакомившихся с SQL. Поскольку специалисты большая редкость, то слышать правильные термины и утверждения дорогого стоит. Что не удивительно, первым же вопросом после доклада бы вопрос про пейджинг, где участник использовал слово "пагинация" (первая фаза осознания: отрицание). Кирилл рекомендовал познакомиться с навигацией по курсору, которому Кирилл посвятил 2 или 3 статьи на хабре и коротко сказал о сути правильной навигации по выборке.
Комментарий от меня: зло потому, что при постраничном выводе можно легко ошибиться, что приведёт к тому, что клиент не увидит часть строк. Чтобы такого не произошло, клиент должен при каждом новом запросе передавать значение, с которого он хочет продолжить получать данные. Кириллу пришлось в ответе на ещёодин вопрос повторять "LIMIT OFFSET почти всегда зло". И это ещё Кирилл не упомянул про WITH TIES.
Как детализация статистики замедляет планировщик PostgreSQL и как это исправлять
Доклады на конференции шли до 19:00 и вечером выступал Илья Евдокимов (Тантор Лабс). Илья написал код для ядра PostgreSQL, который позволяет выполнять поиск соответствия по двум спискам значений. Поиск соответствия выполняется во многих задачах. Например, один список - наиболее часто встречающихся значений (MCV), являющихся частью статистики, собираемой автовакуумом и командой ANALYZE. Второй список - значения в предикатах после операторов IN (,,,), NOT IN (,,,), OR, ANY. Такие списки могут быть внушительными, поиск соответствия со значениями MCV, может увеличивать общее время (планирование+выполнение) запроса.
Код был использован в патче для планирования выполнения соединений (JOIN). Патч был закоммичен в 19 версию Томом Лейном. Про этот патч на Хабре есть статья. В докладе Илья сказал, что уже создал три патча для ускорения работы планировщика со списками в других операторах. Патч для списков в операторе IN уже на коммитфесте https://commitfest.postgresql.org/patch/6356/ . Также есть патч для оператора NOT IN https://commitfest.postgresql.org/patch/6519/
Опыт эксплуатации, проблемы и производительность PostgreSQL на Эльбрус, Baikal-S, Loongson/Иртыш, Repka Pi, x86
Константин Ващенков (Хи-Квадрат) поделился опытом работы PostgreSQL на процессорах:
Нагрузочные тесты длились до 36 месяцев. Константин поделился результатом: все Репки сгорели, не одна-две, а все. С другими процессорами проблем не было. Эльбрусы тестировали 2 года, они работали без проблем
На операциях чтения 1 ядро Иртыша (Loongson) равно 2 ядрам Эльбруса. На операциях изменения и смешанной нагрузки удивительно, но по результатам теста один в один. Если нужно 64 ядра и три потока, то получается нужно либо 1 сервер с Иртышом, либо 4 сервера с Эльбрусом.
О том, что есть китайские и индийские процессоры, я знал, но они не экспортируются. Про существование Иртыша я узнал из доклада Константина
Я не видел более детального и долгого тестирования архитектур процессоров. Флагманский продукт Хи-Квадрат представляет собой сервер приложений с скомпилированным кодом и, думаю, Константин обладает уникальными знаниями по работе процессоров на операционных системах и возможностям оптимизации приложений. Про операционные системы Константин сказал, что при использовании Альт при переносе промышленных приложений с x86 разницы не заметить. Для процессоров ARM более стандартной и перспективной Константин считает ветку Дебиан (Debian/Astra).
Почему-то в вопросах больше всего упоминался Эльбрус, хотя для меня перспективы архитектуры VLIW очевидны со времён Itaniumа. Списываю это на то, что на стенде Хи-Квадрат на видном месте лежала коробочка с надписью Эльбрус, а коробочек с другими надписями не было. Коробочка имела красивый дизайн и ее расположение на столе было настолько удачным, что с коробочкой все фотографировались
Временные таблицы для Postgres. Почему это важно для платформы 1С и что можно улучшить?
Павел Селезнёв (Pangolin) сделал качественный доклад на прошлом PG BootCamp и участвовал в этот раз.
Из интересного, Павел сказал, что СУБД Postgres Pro и Tantor Postgres поддерживают параллельный SELECT из временных таблиц, а Tantor Postgres поддерживает ещё и параллельный INSERT.
Традиционно, про сувениры
Ручки были качественные, пластик очень приятный на ощупь. Я бы даже сказал, что эта ручка занимет первое место, среди тех, которые раздавали на разнообразных конференциях. Значок со слоником небольшого размера, из стильной стали, благодаря размеру значок можно носить
Заключение
Я впервые посетил PG BootCamp, до этого смотрел трансляции. Организация отличная, мне не было скучно. Докладчики были доступны во время конференции и можно было пообщаться и задать вопросы. Доклады были в трёх залах и присутствовать на всех бы не удалось. Ссылка на онлайн-трансляцию https://facecast.net/v/clients/pgbc2026msk.html доступна всем и можно пересмотреть доклады сразу после конференции. Прогресс не стоит на месте: в прошых годах доклады выкладывались через какое-то время.
Эта неделя богата событиями в мире Postgres. Следующее после PG BootСamp Russia событие - PGRun 2026, которое прошло (точнее пробежало) 22 марта. Цены на пробежку не повышались и пробежать можно было бесплатно:
