В статье обзор пяти докладов прошедшей в апреле 2025 года конференции PgBootcamp. Даже на тех конференциях, которые я посещал, мне было бы интересно почитать обзор докладов, но я их не встречал. Иногда можно найти статью к докладу, но для большинства докладов на конференциях такого формата нет. По какой-то причине, обзоры докладов с конференций - редкость. Я решил написать обзор, возможно он окажется полезен.

Доклады конференции PgBootcamp недавно выложили в общий доступ и их можно скачать и посмотреть.

 Введение

Доклады конференций полезны тем, что содержат описание того, что актуально при работе с PostgreSQL. Организаторы выбирают наиболее интересные доклады и не пропускают то, что уже всем известно.

О конференции PgConf я знал давно, а о конференции PgBootcamp я узнал год назад. За это время прошли три конференции: в Казани, Минске и Екатеринбурге. Архив докладов есть на сайте pgbootcamp.ru (регистрироваться на сайте не нужно, в "Программе" - список докладов, внизу каждого доклада ссылка на видеозапись доклада).

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

Видео докладов нарезают и выкладывают в youtube (без рекламы, с транскриптом) и rutube (недостаток рутюба - есть реклама). Презентации и скрипты (если в докладе был технический пример) выложены на гитхаб, ссылки в виде QR-кода дают в самом докладе. Транскрипт полезен, но без прослушивания речи сложно понять о чём идёт речь, так как в тексте нет интонаций, а доклад это не сухое изложение, как в книгах.

У конференций есть чаты и они полезны. Например, в Непале 5 мая проходила  непальская конференция PgConf, я на нее не зарегистрировался, так как она иностранная и небесплатная. Мне хотелось посмотреть хотя бы фотографии - как она выглядит. Где смотреть? Пошел задавать этот вопрос в чат российской PgConf, а в чате фотографии уже были выложены. Между конференциями в чате не пишут, поэтому спама нет. У PgBootcamp один чат для всех конференций и это удобно.

 Вступления

 Два коротких вступления позитивны и их приятно посмотреть. Говорилось, что с 2017 организуются конференции. В 2023 году Брюс Момжан с Михаилом Гольдбергом придумали формат конференций-буткампов, поэтому PgBootcamp проходит под эгидой сообщества. Второе приветствие участникам конференции сделал Брюс Момжан на английском. На непальской конференции Брюс также сказал приветственное слово.

Первый доклад

Смотреть доклады я бы начал с второго потока (второго зала), так как там доклады не такие технически-зубодробительные. Я начал с доклада Александра Никитина "Работа с запросами с точки зрения DBA". Александр был докладчиком и на апрельском PgConf и на предыдущих конференциях.

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

Интересный момент: при оптимизации сначала стоит понять, что хотел сделать автор запроса. Правильные утверждения: не стоит переоценивать индексы, посмотрите собранную статистику. Не собирайте, а посмотрите. На вопрос "как часто собирать статистику", который вызван известным и вредным мифом про благотворность актуализации статистики, был дан ответ: вручную не собираю.

Поддержку дают ванильному PostgreSQL, Postgres Pro не поддерживают, так как он совсем не ванильный. Изменений много, в код посмотреть нельзя, а это иногда полезно, поэтому стоит обращаться в техподдержку PostgresPro. То, что сторонним компаниям сложно осуществлять поддержку Postgres Pro для меня было новым.

К консультантам обращаются, обычно, когда штатные и тоже квалифицированные администраторы PostgreSQL сами не справились. Сначала с проблемами пытаются обратиться в техподдержку (если она есть). Техподдержке тратить огромные ресурсы на исследование частной проблемы нет смысла, так как проблема обычно вызвана ошибками администрирования и некачественно разработанным приложением (кривые запросы и способ хранения данных). Поэтому, если обращение не связано с багом, то ответ поддержки будет с сарказмом: "так работает постгес". В переводе на язык клиента:  "изучите как работает постгрес, чтобы так не делать". Поэтому к консультантам обращаются с нетривиальными проблемами и их труд сложный.

Утрированный пример: стандартными средствами не смогли мигрировать приложение на постгрес с другой базы данных. Консультанты написали надо до миграции менять структуры хранения, трудоемкость задачи возрастает. Заказчик покупает продукт для миграции на постгрес. Продукт не работает. Выясняется причина - в таблицах исходной базы есть столбцы с названиями ctid и при миграции возникают ошибки:

create table t (ctid numeric);
ERROR:  column name "ctid" conflicts with a system column name

Мнение клиента - продукт не работает, поддержка не решает проблему. Мнение разработчика продукта: похже надо выпускать сборку "Unbelivable Edition". Клиент возвращается к консультантам, но уже с опытом.

После доклада был задан вопрос "какие утилиты порекомендуете?". Этот вопрос актуален и его часто задают. Если читатель этой статьи планирует выступать с докладами: ваше мнение об утилитах мониторинга интересно слушателям, но его не всегда успевают задать и можно в докладе об этом заранее сказать. Александр ответил на вопрос: набор скриптов DataEgret и своих, под каждую задачу подбирается свой инструмент.

Второй доклад

 Следующий интересный доклад Павла Селезнёва из Панголина про реализацию сжатия данных. Речь правильная, в хорошем темпе, без воды, приятно слушать. Был упомянут Антон Дорошкевич в начале и в конце доклада, что политкорректно и располагает.

В начале доклада - короткий обзор теории сжатия. Упомянуто, что для zstandard есть длина 860 байт, свыше которой сжатие имеет смысл при передаче по сети, по данным Амазон. Дан обзор алгоритмов сжатия zstandard, deflate, lz4, pglz. Перечислены расширения pgsql-gzip, pgbrotli (хорош для заимствования кода), postgres-protobuf, которыми можно добавить любой существующий алгоритм сжатия. Рассказывалось про сжатие wal, TOAST с результатами тестов.

Если сжимается 8-килобайтный блок, то из-за небольшого размера данных устанавливать высокие степени сжатия для алгоритмов нет смысла. Работа по переносу проприетарных изменений в форках в следующую версию PostgreSQL тяжела, выделяются отдельные люди.

Третий доклад

Следующий доклад, который бы я рекомендовал - "Апгрейд каталогов PostgreSQL и Greenplum", даже если вы с greenplum не работаете. Доклад не про greenplum, а про то, как решаются задачи слияния программного кода. Я узнал, что такое  "черрипик", что уметь программировать для cherry-pick необязательно, но используя эту методику можно назвать себя программистом и даже стать контрибьютором.

После того, как закрыли проект Greenplum, российские контрибьюторы Greenplum хотели создать свой проект, но не смогли договориться и стали делать каждый свой. В апреле 2025 года Аренадата купила разработчика Proxima DB (форк PostgreSQL) и переименовала его в Arenadata Prosperity. Очень хорошо, что у компании быстрая реакция - это показывает разумность, но про переименование вспоминается Рината: "Что-то, как-то, прям, я не знаю...": Проксима - ближайшая к солнцу звезда, а Просперо - революционер из детского фильма "Три толстяка". Сбермаркет -> Купер.

Про Greenplum я давно и часто слышал. Я для себя составил впечатление, что это кластер для отчётов на древнем коде, к которому нет ни нормальных курсов, ни документации. К околопостгесным технологиям, помимо greenplum, относятся citus, patroni, etcd.

Дальше тезисы доклада, которые мне показались интересными.
Hironobu Suzuki разрешил Кириллу Решке использовать картинки из своей книги "The Internals of PostgreSQL", а Андрею Бородину не разрешил! При этом Андрей был в зале, слушал доклад и после доклада даже задал вопрос, но не про Хиронобу Судзуки, так как Кирилл в начале доклада сказал про причину, по которой Андрей впал в немилость у Хиронобу. Это расслабило и настроило меня на более лёгкое восприятие доклада. Делайте поправку на то, что докладчики волнуются и Кирилл шутил с серьёзным видом. Я смотрел доклад архитектора из Аренадаты, описание ситуации с гринплумом (за год до закрытия проекта перестали принимать патчи) полностью совпала и я еще раз проникся доверием к докладу Кирилла. Дальше - то, что мне запомнилось.

Китайцы выпустили Cloudberry, они знали на год раньше, что Greenplum закроется. Cloudberry - это тоже greenplum, только основан на другом ядре постгреса. У Greenplum две основные версии 6 и 7 и основаны они на PostgreSQL 9.4.

Гринплум существовал с 2007 года с какой-то древней версии постгрес. В гринплуме был Хейки, который был коммитером постгрес и поэтому более менее гринплум работал. У гринплума есть версия 6, основанная на постгрес 9.4 и он может работать в продакшн. Гринплум версии 7 разваливается на ходу (это не секрет) и не может работь в проде. Cloudberry основан на гринплум 7, но доделан. Плюсы Cloudberry в том, что его разарбатывает в 10 раз больше программистов, чем другие форки и версия постгрес новее.

Runtime filter - технология 2007 года, которую Хейки выкинул потому, что у него она не давала ускорение, Кирилл тоже измерял и тоже производительности не увидел.

Кирилл сказал, что хочет добавить Create index progress, который никому не нужен кроме него. По названию я подумал, что это pg_stat_progress_create_index и проникся состраданием к гринпуму, как люди мучаются без того, что давно есть в постгресе. Compute storage separation называется Yezzy.

Технология FAST TEMP -  актуальна для постгреса. Создание временных таблиц и зависимых объектов приводит к вставке в таблицы системного каталога, причем не просто pg_class и pg_attribute, а ещё в 11 таблицах. наибольшие объемы вставляется в не только в pg_attribute, но и в pg_depend, pg_type.

postgres=# \dconfig enable_temp_memory_catalog
  List of configuration parameters
         Parameter          | Value 
----------------------------+-------
 enable_temp_memory_catalog | on
(1 row)

Кирилл сказал, что ничего они не писали, а «стащили» патч Алексея Алексеева и хотят закоммитить в свой гринплум. То есть предпинимаются попытки переписать логику работы с временными таблицами и PostgreSQL, но это непросто - вопрос в качестве патча, но это меньшая проблема для гринплума.

Дальше был переход к сути доклада: как из гринплума сделать coludberry. Как из одной постгресподобной баз перетащить изменения в другой постгрес. Называется эта технология chery-pick. Программировать для этого нужно, нужно выбитать строки кода diffом и аккуратно выписывать изменения в Экселе и проверять, чтобы не было конфликтов. То есть выписать 3000 коммитов в табличку, посмотреть где нет конфликтов и отметить те коммиты, которые хочется перенести. Проблема обновлений в Cloudberry отсутствие обсуждений и плохое документирование: нет комментариев «зачем что делалось».

Был приведен пример расширения pgaudit и на слайд была вынесена функция pg_event_trigger_ddl_commands и "???". При конфигурировании этого расширения меня тоже не покидало ощущение «???», как будто его бросили писать на полпути. В ванильном постгресе оно отсутствует. Причины наверняка есть - только с виду может казаться, что нужно немного доработать, а код legacy, чуть тронешь и развалится. Надеюсь Кирилл справится с кодом pgaudit и можно будет черрипикнуть его код. Не всё же гринплуму черрипикать из Постгреса.

Был дан ответ на вопрос "Почему Постгрес расширяемый?" Я тоже задавался этим вопросом. Оказалось, что это пришло из статьи Майкла Стоунбрейкера, где он написал, что Постгрес расширяемый. С того времени, из уважения к отцу-основателю, считается, что Постгрес расширяемый. Приведена таблица, что расширение индексных методов доступа появилось с версии 9.6, табличных с 12 версии, custom rmgr с 15 версии.

Был озвучен краеугольный вопрос: а нужен ли гринплум? Кирилл, поддерживающий форк Greenplumа без обиняков сказал: cкорее всего не нужен. И в том виде, в котором он сейчас есть он не был бы нужен, если бы Постгрес был расширяемым, то гринплан был бы расширением. Кирилл дал реальную оценку: возможно, светлое будущее гринплума - стать расширением Постгреса. Для консистентности экземпляров гринплума был бы полезен CSN (commit sequence number). Хейки пытался вкоммитить в 18 Постгрес, но хорошо, что не закоммитили и оставили в статусе WIP (work in progress), так как патч сырой. Возможно, с 20-21 версии Постгрес, Greenplum удастся оформить как расширение.

Дальше в докладе приводится пример вставки bloom-фильтрации в гринплум. С 14 версии Постгрес есть BRIN индекс с возможностью bloom фильтрации. Дальше были технические детали с аккуратными картинками, но из-за вскипания мозга я их не стал смореть.

Перейти с гринплума в cloudberry можно pg_dumpом, но из-за объемов это неприемлемо долго. В докладе описывается идея, что можно было бы это проделать утилитой pg_upgrade. Те, кто хранит террабайты в гринплум могут ждать появление способов миграции на что-то новое - Cloudbarry или другие форки гринплума. Возможно, дождутся.

Понравилось то, что Кирилл прямо и без политесов озвучил актуальные вопросы. Я тоже считаю, что обманываться и самообманыаться нельзя, нужно задаваться любыми вопросами в самой неудобной форме и тогда можно будет найти решение. А если не осветить проблему по причине политкорректности, то и решене не будет искаться, а важен результат. Кирилл и другим докладчикам задавал прямые вопросы типа: "ваше расширение портит данные, нужно ли оно вообще". Также сказал, что не понимает зачем нужны семейства операторов, если есть классы операторов. Над этим бились лучшие умы и нашли только одну причину. В целом, я сделал вывод, что работа с кодом 9 версии Постгрес совсем не доставляет удовольствия, хорошо, что я не знаком с гринплумом. Доклад укрепил в намерении ещё тщательнее изучать Постгрес и не смотреть на всякие гринплумы.

Доклад: Как "выкопать" данные из нечитаемых таблиц?

Меня заинтересовал стиль докладчика, а также возможность расслабиться перед переходом к более сложным докладам. В докладе интересно послушать часть про пример использования утилиты pg_filedump. Если стиль не понравится, то доклад можно пропустить. Приведен простой блок на plpgsql, с помощью которого можно прочесть читаемые строки. В песочнице есть статья с кодом этого блока  https://habr.com/ru/sandbox/241194/ Про использование pg_filedump есть короткая статья Александра Алексеева: https://habr.com/ru/companies/postgrespro/articles/323644/

Правильные моменты доклада: не лечить симптомы, а выяснить причину повреждений; лучше всего иметь правильно созданные бэкапы. Поправка к докладу: в ctid (block_number, line_number) - line number может быть больше 255.

Доклад: Изменение структуры таблиц в PostgreSQL «на лету» с помощью технологии dbms_redefinition

Доклад про dbms_redefinition прост и интересен как описание пошаговых действий процесса, по которому можно внести изменения в таблицы с минимизацией простоя. Процедура взята из опции Online Redefinition, имеющийся в Oracle Database. Физически это набор процедур в пакете с названием dbms_redefinition. Ничего чудесного и низкоуровневого нет, полностью повторяет процедуры пакета в Oracle Database. Расширение еще не выложено, после доработки должен быть выложен на гитхаб. Доклад простой и понятный.

Чем меньше допустимое время простоя, тем более муторна процедура и заниматься ей можно только, если некуда деваться. Online Redefinition интересен тем, что это испанское наследство одна из набора опций Oracle Database, которую считают возможным реализовать в PostgreSQL. Online redefinition, ILM (Information Lifecycle Management - автоматическое перемещение таблиц между табличными пространствами со сжатием и без сжатия), Automatic Indexing (автоматическое создание аналитических индексов) - любимые опции пресейла.

 Доклад: Cтатический анализ баз данных PostgreSQL против скрытых ошибок

 Название доклада слишком общее. Докладчик преподавал в ВУЗе, поэтому используются академические термины. Это доклад про скрипты github.com/sdblist/db_verifier/ которые выполняют быструю проверку структур хранения и предупреждают о типичных недостатках. Например, имеются два индекса, отличающиеся только по названиям. Скриптами можно провести быструю проверку, вдруг проверки на что-то обратят внимание.

 Заключение

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