Прошла пятая ежегодная конференция PG BootСamp Russia. В этот раз она проводилась в Москве 19 марта 2026 года. 563 оффлайн участника и порядка 1300 онлайн. Первая конференция прошла в 2023 году и дальше проводилась в разных городах. В статье - репортаж с конференции и краткий обзор докладов.
Идею проводить PG BootCamp придумали Михаил Гольдберг и Брюс Момжан
Открывали конференцию члены оргкомитета: PostgreSQL Major Contributor Андрей Бородин (Yandex Cloud) и генеральный директор Тантор Лабс Вадим Яценко
На сцену пригласили Ивана Кузьмина (СКАЛА-Р), который не пропустил ни одной конференции, включая юбилейную этого года. Стабильность и предсказуемость - свойство реляционных баз данных. Ивану хотели дать бесплатный билет на конференцию, но увы, конференция PG BootCamp бесплатна для участников, поэтому Ивану вручили другую награду.
По традиции, участников конференции приветствовал Брюс Момжан:
Архив будущего
Первым докладом был доклад Андрея Бородина "Архив будущего". В докладе описывались актуальные проблемы архива WAL.
Андрей отметил удачную идею линий времени (timelines). Бэкап может начатья на одной линии времени, а закончиться на другой. И с такого бэкапа можно будет восстановиться. Такой бэкап будет создан, если реплика (или какая-то реплика до той, с которой берётся бэкап) стала мастером. Такое возможно в случае запланированного переключения (switchover).
Вторая особенность, которая рассматривалась в докладе: перед переключением на нового мастера старый, начинает останавливаться. При остановке выполняет финальную контрольную точку и может это делать долго. Если не дождаться завершения контрольной точки и выполнить promote одной из реплик, то старый мастер придется возвращать в строй утилитой pg_rewind.
Андрей предложил патч, устраняющий проблему одновременной архивации 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 Вадим делал доклад о том, какие особенности встречались при работе с 25 серверами PostgreSQL в 2 центрах обработки данных с суммарным объем хранящихся данных 300ТБ, которые обслуживали систему Платон. В то время был большой секпсис относительно использования PostgreSQL и продвигать его было сложно.
Александр Коротков, один из основателей компании Postgres Professional, после ухода из которой, создал OrioleDB и, в настоящее время, единственный коммитер из России, выделил 10 проблем:
Вадим выразил мнение, что шардинг в PostgreSQL для OLTP нагрузки - не рабочая схема. Мне это понравилось, потому, что я такого же мнения об этой технологии, что для PostgreSQL, что для Oracle и в ней больше моды, чем технической составляющей. Специалисты, которые поддерживают реальные системы, не следуют моде, а используют реальные технологии. Я был рад, что не так давно OpenAI поделились описанием архитектуры хранения данных с использованием 50 реплик PostgreSQL.
Мне также нравится политика сообщества Postgres Development Group, благодаря которой PostgreSQL не обрастает кучей костылей, а сообщество может позволить себе включать в PostgreSQL только качественные улучшения.
Дальше Вадим перешел к описанию тех возможностей, которые Тантор Лабс нашел и стал дорабатывать. Были взяты технологии Alibaba Polar. Технологии много лет, но она не привлекала внимание, хотя и упоминалась наряду с решениями Amazon.
Не буду описывать то, что было в докладе. Для себя я выделил основные моменты: 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 по своим центрам (геомирроринг), это оправданно для облачных компаний. Для компаний, не являющихся облачными провайдерами, проще и производительнее разнести две Oracle Exadata или Tantor xData по своим центрам и связать их (RAC в Oracle Exadata или Tantor Polar в xData) физической репликацией.
В Polar один запрос может использовать параллельные процессы на всех экземплярах, точно так же, как и Oracle RAC. Это позволяет обрабатывать запрос, задействуя все вычислительные узлы. В докладе приведен пример TPC-H теста на Tantor xData Gen3, состоящей из 3 вычислительных и 3 узлов хранения на процессорах AMD и системных платах Supermicro. Конфигурация: один мастер и две реплики. На узлах одновременно запускались тесты pg_bench (TPC-B), выдающих 204000 TPS (на 3 узлах). Одновременно и на тех же узлах запускался TPC-H. Q1 запускался в 128 потоках и выполнился за 11,77 секунд. Q2 - 3,451 секунды. Планировщик GPORCA и параллельное выполнение на всех узлах с динамическим выбором степени параллелизма с ограничением в 128 процессов (MAX_DOP=128). Да, вам не показалось, в Tantor Polar используется планировщик GPORCA.
Технические подробности Tantor Polar описывал Алексей Копытов в следующем же докладе "Разделение compute и storage: архитектурный прорыв для PostgreSQL в облаке". Я выделил для себя следующие моменты: Tantor Polar использует 15 версию PostgreSQL, но ведется перебазирование на 17 версию; Alibaba совсем недавно выложил Alibaba Polar для 17 версии; Добавление, запуск дополнительных экземпляров выполняется динамически, это позволяет без остановки масштабировать нагрузку.
На буткэмпе была фотомашина, которая фотографировала:
И печатала фотографию с Tantor xData. Можно было сфотографироваться с участниками и участинцами конференции:
Реально работающая машина Tantor xData Gen3 стояла неподалёку и выполняла тесты. С ней тоже можно было сфотографироваться:
На выставке я не обратил внимание, а на фотографии обратил: на экране слева выведена страница Платформы Тантор, которая мониторила экземпляры кластеров PostgreSQL Tantor xData, на которой всё время выставки работали нагрузочные тесты. Я зашёл за стойку с xData и из неё выдувался плотным потоком теплый воздух.
После обеда был доклад уважаемого члена сообщества, контрибьютора Андрея Лепихова (pgEdge), разработавшего Multimaster.
Андрей живёт в Мадриде и выступал по телемосту. Качество звука было отличное:
Валим "слона"
После доклада Андрея шел доклад Кирилла Боровикова (Тензор). Кирилл много лет занимается анализом планов выполнения запросов:
Я считаю, что Кирилл лучше всех в мире (да, во всём мире) умеет писать запросы SQL. Я могу оценивать профессионализм, у меня есть справка:
Кирилл Боровиков (@Kilor) опубликовал на Хабре 182 статьи. По оценке Кирилла, особенности 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 уже на коммитфесте. Также есть патч для оператора NOT IN.
Опыт эксплуатации, проблемы и производительность 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, до этого смотрел трансляции. Организация отличная, мне не было скучно. Докладчики были доступны во время конференции и можно было пообщаться и задать вопросы. Доклады были в трёх залах и присутствовать на всех бы не удалось. По этой ссылке на онлайн-трансляцию можно смотреть доклады в любое время без паролей и регистраций, проматывать их. То есть просмотр докладов доступен с момента их появления всё время. Удобно то, что доклады можно просматривать на увеличенной скорости.
UPDATE 26.03.2026: Через 2 дня после конференции были выложены презентации докладов: https://github.com/PGBootCamp/Russia_2026
Часть людей не может поверить, поэтому повторю - записи докладов PGBootCamp уже в открытом доступе и доступны по ссылке без регистраций https://facecast.net/v/clients/pgbc2026msk.html
Доклады конференции PgConf, которая прошла сразу после PGBootCamp, тоже доступны по "секретной" ссылке, но нужно ввести пароль, который давался только участникам конференции (и онлайн и оффлайн участникам).
В чате конференции https://t.me/pgbootcamp докладчики отвечали на вопросы, которые задавали уже после конференции. Мне понравился вопрос про O_DIRECT в PolarFS, описывающий тонкий момент. То, что fsync() и fdatasync() пропихивают блоки через кэши физических устройств, так как в них тоже есть кэш на запись я знал ("includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed").
Также O_FUA пропихивает, но о деталях работы O_DIRECT я не задумывался. Меня впечатлило, что разработчики Tantor Polar уделили внимание этой особенности, которая напрямую влияет на отказоустойчивость.
Скрытый текст
Вопросы к докладу Алексея Копытова «Разделение Compute и Storage: архитектурный прорыв для PostgreSQL в облаке»
❔Вопрос к слайдам 21/22. Зачем нужно было реализовывать fsync(), если на слайде 21 упоминается, что PolarFS работает в O_DIRECT режиме? Возможно, поэтому fsync() и был no-op?
Ответ: Tantor Polar, как и PostgreSQL, для обеспечения долговечности данных вызывает сброс буферов на диск через аналог fsync() — в API PolarFS это pfsd_fsync() (и соответствующий вызов в libpfs). Без реальной реализации этого вызова нельзя гарантировать, что после сбоя питания или падения узла записанные данные действительно окажутся на постоянном носителе.
В оригинальной открытой реализации PolarFS вызовы pfsd_fsync() и pfs_fsync() были пустыми операциями (noop): они ничего не делали. Причины в коде не задокументированы. Возможные объяснения - в облачной версии PolarFS поверх PolarStore запись могла считаться «автоматически устойчивой» (например, семантика вроде O_SYNC на уровне хранилища). Для блочного устройства (бэкенд PFS_DEV_DISK), которое мы используем, это не применимо. Или же разработчики могли считать, что раз PolarFS использует только небуферизованный I/O (O_DIRECT), явный fsync() не нужен.
На деле O_DIRECT лишь обходит кэш страниц ОС и гарантирует попадание данных в кэш устройства, а не обязательно на энергонезависимый носитель. Считать запись устойчивой можно только если железо гарантирует защиту от потери питания (PLP), а в общем случае — и тем более в программно-определяемом хранилище — полагаться на это нельзя.
Поэтому в нашей доработанной PolarFS исправлено: при вызове pfsd_fsync() / pfs_fsync() теперь принудительно выполняется сброс кэша записи нижележащего блочного устройства (аналог flush на уровне диска). Поведение включается опцией конфигурации diskdev_flush_enable (по умолчанию включено). Это даёт Tantor Polar корректную гарантию долговечности при использовании PolarFS на произвольном блочном устройстве или кластере хранения.
Эта неделя богата событиями в мире Postgres. Следующее после PG BootСamp Russia событие - PGRun 2026, которое прошло (точнее пробежало) 22 марта. Цены на пробежку не повышались и пробежать можно было бесплатно:
На следующий день, после PGRun, прошла двухдневная конференция PGConf.Pоссия 2026. Она была такая же интересная, как PGBootcamp. Короткий обзор докладов PGConf есть в статье Postgresso #2 (87).
