По следам конференции PG BootСamp Russia 2026, прошедшей 19 марта

OlegIct4 часа назад

По следам конференции PG BootСamp Russia 2026, прошедшей 19 марта

Уровень сложностиПростойВремя на прочтение10 минОхват и читатели2.8KPostgreSQL*РепортажПрошла пятая ежегодная конференция PG BootСamp Russia. В этот раз она проходила в Москве 19 марта 2026 года. 563 оффлайн участника и порядка 1300 онлайн. Первая конференция прошла в 2023 году и дальше проводилась в разных городах. В статье - репортаж с конференции и краткий обзор докладов.

Идею проводить PG BootCamp придумали Михаил Гольдберг и Брюс Момжан

членов сообщества надо знать в лицо: Major Сontributor Анастасия Лубенникова и Михаил ГольдбергОткрывали конференцию члены оргкомитета: PostgreSQL Major Contributor Андрей Бородин (Yandex Cloud) и генеральный директор Тантор Лабс Вадим Яценко

PostgreSQL Major Contributor Андрей БородинНа сцену пригласили Ивана Кузьмина (СКАЛА-Р), который не пропустил ни одной конференции, включая юбилейную этого года. Стабильность и предсказуемость - свойство реляционных баз данных. Ивану хотели дать бесплатный билет на конференцию, но увы, конференция PG BootCamp бесплатна для участников, поэтому Ивану вручили другую награду :-)

По традиции, участников конференции приветствовал Брюс Момжан:

приветствие участникам PG BootCamp 2026Брюс будет участвовать 30 апреля в PGDay Armenia

Архив будущего

Первым докладом был доклад Андрея Бородина "Архив будущего". В докладе описывались актуальные проблемы архива WAL.

Андрей отметил удачную идею линий времени (timelines). Бэкап может начатья на одной линии времени, а закончиться на другой. И с такого бэкапа можно будет восстановиться. Такой бэкап будет создан, если реплика (или какая-то реплика до той, с которой берётся бэкап) стала мастером. Такое возможно в случае запланированного переключения (switchover).

Вторая особенность, которая рассматривалась в докладе: перед переключением на нового мастера старый, начинает останавливаться. При остановке выполняет финальную контрольную точку и может это делать долго. Если не дождаться завершения контрольной точки и выполнить promote одной из реплик, то старый мастер придется возвращать в строй утилитой pg_rewind.

Андрей предложил патч https://commitfest.postgresql.org/patch/6177/ , устраняющий проблему одновременной архивации WAL с мастера и реплик, так как используя always, сложно настроить беспроблемную архивацию

патч Андрея Бородина вводит новый режим архивации shared_archiveПри использовании архива WAL процесс startup может использовать restore_command, если этот параметр сконфигурирован. Из-за ошибки с двойной остановкой процесса walreceiver (сигналом SIGTERM), процесс startup может взять WAL-сегмент из архива (сообщение в диагностическом журнале "restored log file from archive"). Процесс startup выполняет restore_command, если walreceiver не может получить журнальные данные. Есть вероятность, что в архив не успеет записаться WAL-сегмент последней линии времени, реплика применит WAL-файл с предыдущей линии времени и останется на ней. Ошибка не позволит реплике работать и такую реплику придется восстанавливать или пересоздавать. В диагностическом логе будут сообщения:

баг приводит к ошибкам, выделенным красным цветомНумерация линий времени в диагностических сообщениях в десятеричной системе, а в названиях файлов history в шестнадцатеричной. Например, при создании timeline 10 создаётся файл 0000000A.history.

Андрей создал патч, исправляющий проблему https://commitfest.postgresql.org/patch/6525/

Также Андрей рассказал об идеях, как можно было бы улучшить работу PostgreSQL. Например, чтобы база данных совмещала все операции массового чтения: резервирование с вакуумированием и сбором статистики. Чтобы за одно чтение все выполнялись все три действия и не нужно было бы повторно читать данные.

Андрей (во втором ряду) слушал доклады на конференции:

Роман Фролов (в синей футболке) тоже слушал доклады, бесстрашно готовясь к своему выступлению про "Бесстрашный PostgreSQL", за ним сотрудник технической поддержки, отвечающий на services requests Романа

Есть ли будущее у генетических и обучаемых методов в оптимизации запросов

После Андрея в основном зале конференции выступила Алёна Рыбакина (Яндекс). Алёна, как никто, детально разбирается в работе планировщика и сделала прекрасный доклад с обзором методов работы планировщика. Алёна сделала детальный обзор методов поиска оптимального порядка соединения таблиц. В докладе также были рассмотрены алгоритмы оптимизации соединений с использованием машинного обучения: SkinnerDB, Neo-TreeCNN, BaoHint+Bandit.

Алёна Рыбакина из Яндекс рассказала об оптимизации запросов SQLАлёна академически точно описала текущее состояние методов оптимизации соединений наборов данных:

современные методы оптимизации выполнения JOINСтатья Алёны месяц назад, 19 февраля, публиковалась на хабре. Надеюсь, статью Алёны не постигнет участь статьи Павла Конотопова, которая внезапно исчезла, так как была написана излишне правдиво. Но интернет всё помнит, и со статьёй Павла можно ознакомиться https://forpes.ru/post/221650 Случился "Эффект Стрейзанд". Могу сказать, что я был восхищён статьёй Павла, так как все утверждения технически верные. Больше всего мне понравилось мнение Павла про Одиссей. Я сторонник открытости, а не замалчивания проблем, так как выявление их выявление помогает улучшать приложения. Боязнь "Что станет говорить княгиня Марья Алексевна" ("Горе от ума", Грибоедов) это виртуальный страх.

Старые архитектурные проблемы PostgreSQL и их решение

После Алёны Рыбакиной выступил Вадим Яценко (Тантор Лабс) с докладом о решениях архитектурных проблем PostgreSQL. За две недели до конференции была опубликована статья https://habr.com/ru/companies/tantor/articles/1007038/ , поэтому доклад вызвал интерес.

PostgreSQL - универсальная СУБД с большим международным сообществом. Вадим давно работает с базами данных большого размера. В 2017 Вадим делал доклад https://pgconf.ru/talk/1588070 о том, какие особенности встречались при работе с 25 серверами PostgreSQL в 2 центрах обработки данных с суммарным объем хранящихся данных 300ТБ, которые обслуживали систему Платон. В то время был большой секпсис относительно использования PostgreSQL и продвигать его было сложно.

Александр Коротков, один из основателей компании Postgres Professional, после ухода из которой, создал OrioleDB и, в настоящее время, единственный коммитер из России https://www.postgresql.org/developer/committers/ , выделил 10 проблем

список архитектурных проблем PostgreSQLВадим выразил мнение, что шардинг в PostgreSQL для OLTP нагрузки - не рабочая схема. Мне это понравилось, потому, что я такого же мнения об этой технологии, что для PostgreSQL, что для Oracle и в ней больше моды, чем технической составляющей. Специалисты, которые поддерживают реальные системы, не следуют моде, а используют реальные технологии. Я был рад, что не так давно OpenAI поделились описанием архитектуры хранения данных с использованием 50 реплик PostgreSQL https://habr.com/ru/news/988632/

Мне также нравится политика сообщества Postgres Development Group, благодаря которой PostgreSQL не обрастает кучей костылей, а сообщество может позволить себе включать в PostgreSQL только качественные улучшения

о шардинге в PostgreSQLДальше Вадим перешел к описанию тех возможностей, которые Тантор Лабс нашел и стал дорабатывать. Были взяты технологии Alibaba Polar. Не буду описывать то, что было в докладе. Для себя я выделил основные моменты: Polar аналогичен Oracle RAC. Это возможность обслуживать один кластер PostgreSQL нескольким экземплярам. Пишущим является только один экземппляр. Для такой работы нужна кластерная файловая система. Для Oracle RAC это ASM или NFS. В Polar это называется PolarFS. Также я проверил, что на конфигурацию PolarDB (кластер, обcлуживаемый несколькими экземплярами) можно создать конфигурацию-реплику PolarDB, аналогично Oracle Data Guard+RAC. То есть можно иметь две PGDATA в разных центрах обработки данных, обслуживаемые каждая из которых своим набором экземпляров. Один запрос может использовать параллельные процессы на всех экземплярах, как и 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 стояла неподалёку и выполняла тесты. С ��ей тоже можно было сфотографироваться:

Tantor xData третьего поколения (Gen3)После обеда был доклад  уважаемого члена сообщества, контрибьютора Андрея Лепихова (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 раза объем передаваемых клиенту данных

привдение типа numeric к integer уменьшает трафик в 4 разаБольше всего мне понравилось, что Кирилл говорит "пейджинг", а не "пагинация". Также абсолютно правильно сказал, что пейджинг по умолчанию зло, но, если бизнес требует, то иногда можно. По используемым терминам можно легко определить настоящих специалистов от недавно познакомившихся с SQL. Поскольку специалисты большая редкость, то слышать правильные термины и утверждения дорогого стоит. Что не удивительно, первым же вопросом после доклада бы вопрос про пейджинг, где участник использовал слово "пагинация" (первая фаза осознания: отрицание). Кирилл рекомендовал познакомиться с навигацией по курсору, которому Кирилл посвятил 2 или 3 статьи на хабре и коротко сказал о сути правильной навигации по выборке.

Комментарий: зло потому, что при постраничном выводе можно легко ошибиться, что приведёт к тому, что клиент не увидит часть строк. Клиент должен при каждом запросе передавать значение, с которого он хочет продолжить получить данные. Кириллу пришлось еще в ответе на один вопрос повторять "LIMIT OFFSET почти всегда зло". И это ещё Кирилл не упомянул про WITH TIES

Как детализация статистики замедляет планировщик PostgreSQL и как это исправлять

Доклады на конференции шли до 19:00 и вечером выступал Илья Евдокимов (Тантор Лабс). Илья написал код для ядра PostgreSQL, который позволяет выполнять поиск соответствия по двум спискам значений. Поиск соответствия выполняется во многих задачах. Например, один список - наиболее часто встречающихся значений (MCV), являющихся частью статистики, собираемой автовакуумом и командой ANALYZE. Второй список - значения в предикатах после операторов IN (,,,), NOT IN (,,,), OR, ANY. Такие списки могут быть внушительными, поиск соответствия со значениями MCV, может увеличивать общее время (планирование+выполнение) запроса.

Код был использован в патче для планирования выполнения соединений (JOIN). Патч был закоммичен в 19 версию Томом Лейном https://commitfest.postgresql.org/patch/5929/ Про этот патч на хабре есть статья https://habr.com/ru/companies/tantor/articles/975808/ В докладе Илья сказал, что уже создал три патча для ускорения работы планировщика со списками в других операторах. Патч для списков в операторе 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 года, они работали без проблем

впечатление о процессоре ARM (Байкал)На операциях чтения 1 ядро Иртыша (Loongson) равно 2 ядрам Эльбруса. На операциях изменения и смешанной нагрузки удивительно, но по результатам теста один в один. Если нужно 64 ядра и три потока, то получается нужно либо 1 сервер с Иртышом, либо 4 сервера с Эльбрусом.

О том, что есть китайские и индийские процессоры, я знал, но они не экспортируются. Про существование Иртыша я узнал из доклада Константина

о процессоре Иртыш (Loongson)Я не видел более детального и долгого тестирования архитектур процессоров. Флагманский продукт Хи-Квадрат представляет собой сервер приложений с скомпилированным кодом и, думаю, Константин обладает уникальными знаниями по работе процессоров на операционных системах и возможностям оптимизации приложений. Про операционные системы Константин сказал, что при использовании Альт при переносе промышленных приложений с x86 разницы не заметить. Для процессоров ARM более стандартной и перспективной Константин считает ветку Дебиан (Debian/Astra).

Почему-то в вопросах больше всего упоминался Эльбрус, хотя для меня перспективы архитектуры VLIW очевидны со времён Itaniumа. Списываю это на то, что на стенде Хи-Квадрат на видном месте лежала коробочка с надписью Эльбрус, а коробочек с другими надписями не было. Коробочка имела красивый дизайн и ее расположение на столе было настолько удачным, что с коробочкой все фотографировались

коробочка с надписью Эльбрус на стенде Хи Квадрат

Временные таблицы для Postgres. Почему это важно для платформы 1С и что можно улучшить?

Павел Селезнёв (Pangolin) сделал качественный доклад на прошлом PG BootCamp и участвовал в этот раз.

Из интересного, Павел сказал, что СУБД Postgres Pro и Tantor Postgres поддерживают параллельный SELECT из временных таблиц, а Tantor Postgres поддерживает ещё и параллельный INSERT.

Традиционно, про сувениры

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

ручка с логотипом конференции PG BootCamp

Заключение

Я впервые посетил PG BootCamp, до этого смотрел трансляции. Организация отличная, мне не было скучно. Докладчики были доступны во время конференции и можно было пообщаться и задать вопросы. Доклады были в трёх залах и присутствовать на всех бы не удалось. Ссылка на онлайн-трансляцию https://facecast.net/v/clients/pgbc2026msk.html до сих пор доступна и можно пересмотреть доклады сразу после конференции. Отлично, что конференция была бесплатной для участников.

Эта неделя богата событиями в мире Postgres. Следующее событие - PGRun 2026. Можно бесплатно совершить традиционную пробежку с Major Contributor Олегом Бартуновым:

PGRun 2026Теги:• конференция • postgres • postgresqlХабы:• PostgreSQL