Обзор пяти докладов конференции PgBootcamp 2025
В статье обзор нескольких докладов прошедшей в апреле 2025 года конференции PgBootcamp. Даже на тех конференциях, которые я посещал, мне было бы интересно почитать обзор докладов. Все доклады прослушать сложно из-за нехватки времени, а упускать из внимания интересные моменты, озвученные где-нибудь в середине доклада, не хочется. Также мне было бы интересно мнение других людей — совпадает ли оценка докладов с моей оценкой. По какой-то причине обзоры докладов конференций и репортажи с них редкость.
Доклады конференции PgBootcamp недавно выложили в общий доступ и их можно скачать и посмотреть. Смотреть все доклады долго, а так как они технические, то вникать во всё сложно.
Просмотр докладов в формате видео занимает много времени. Было бы удобнее их просматривать в виде статей, но для большинства докладов конференций нет такого формата.
Введение
Доклады конференций полезны тем, что содержат описание того, что актуально при работе с PostgreSQL. Организаторы выбирают наиболее интересные доклады и не пропускают то, что уже всем известно. По большинству докладов не оформлено статей.
О конференции PgConf я знал давно, это самая популярная конференция, которая проходит два раза в год уже больше, а о конференции PgBootcamp я узнал год назад. За это время прошли три конференции: в Казани, Минске и Екатеринбурге. На конференцию можно бесплатно зарегистрироваться онлайн и оффлайн. Конференция однодневная параллельно в двух залах. Польза регистрации в том, что даётся ссылка на трансляцию и можно просматривать после окончания конференции. Без регистрации доклады становятся доступны только через 2–3 недели.
Видео докладов нарезают и выкладывают в youtube (без рекламы и с с транскриптом, но надо подключатья) и rutube (с рекламой). Презентации и скрипты (если в докладе был технический пример) на гитхабе. Транскрипт полезен, но на практике без прослушивания речи сложно понять о чём идёт речь, так как в тексте нет интонаций, а доклад это не сухое изложение, как в книгах.
У конференций есть чат в телеграм и чаты полезны. Например, в Непале ~5 мая проходила непальская конференция PgConf, я на нее не зарегистрировался, так как она иностранная, небесплатная. Мне хотелось посмотреть хотя бы фотографии — как она выглядит. Где смотреть? Пошел задавать этот вопрос в чат российской PgConf и не задал, потому, что в каком-то из чатов фотографии уже были выложены. Было приятно увидеть знакомые по российским PgConf лица, особенно несравненную Екатерину Соколову.
Дальше обзор докладов нескольких докладов конференции.
Вступительные выступления
Два коротких вступления позитивны и их приятно посмотреть. Говорилось, что с 2017 организуются конференции. В 2023 году Брюс Момжан с Михаилом Гольдбергом придумали формат конференций-буткампов, поэтому она проходит под эгидой сообщества. Второе приветствие участникам конференции сделал Брюс Момжан на английском.
Первый доклад
Смотреть доклады я бы начал с второго потока (второго зала), так как там доклады не такие технически-зубодробительные. Я начал с доклада Александра Никитина »Работа с запросами с точки зрения 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 и своих и под задачу подбирается свой инструмент.
Антон — специалист по 1С и при этом имеет сертификат Эксперта от Postgres Pro, а это сдача четырёх сложных экзаменов. Создателям программы сертификации удалось создать аккуратные и выверенные тесты. Проходной балл рассчитывается чрезвычайно точно. Недавно я узнал от очевидца, что вопросы первой и последующих попыток различны и разного уровня сложности, что позволяет исключить получение сертификата, пытаясь сдавать тесты повторно. А также, что при сдаче теста есть поиск по русскоязычной документации. То что документация есть это известно, вопрос был в быстром поиске.
Второй доклад
Следующий интересный доклад Павла Селезнёва из Панголина про реализацию сжатия данных. Речь правильная, в хорошем темпе, без воды, приятно слушать. Был упомянут Антон Дорошкевич в начале и в конце доклада, что политкорректно и располагает.
В начале доклада — короткий обзор теории сжатия. Упомянуто, что для zstandard есть длина 860 байт, свыше которой сжатие имеет смысл при передаче по сети, по данным Амазон. Дан обзор алгоритмов сжатия zstandard, deflate, lz4, pglz. Перечислены расширения pgsql-gzip, pgbrotli (хорош для заимствования кода), postgres-protobuf, которыми можно добавить любой существующий алгоритм сжатия. Рассказывалось про сжатие wal, TOAST с результатами тестов. если сжимается 8килобайтный блок, то из-за небольшого размера данных устанавливать высокие степени сжатия для алгоритмов нет смысла. Работа по переносу проприетарных изменений в форках в следующую версию PostgreSQL тяжела, выделяются отдельные люди.
Третий доклад
Следующий доклад, который бы я рекомендовал — «Апгрейд каталогов PostgreSQL и Greenplum», даже если вы с greenplum не работаете. Доклад не про гринплум, а про то, как решаются задачи слияния программного кода. Я узнал, что такое «черрипик», что уметь писать код для cherry-pick необязательно и используя эту методику разработки можно стать разработчиком.
После того, как гринплум выставили на мороз закрыли проект, российские контрибьюторы гринплама хотели создать свой проект, но не смогли договориться и стали делать каждый свой.
Про 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 и »???». При конфигурировании этого расширения меня тоже не покидало ощущение его корявости, как будто его бросили писать на полпути. В ванильном постгресе оно отсутствует.
Был дан ответ на вопрос «Почему Постгрес расширяемый?» Я тоже задавался этим вопросом. Оказалось, что эта догма пошла из статьи Стоунбрейкера, где он написал, что Постгрес расширяемый. И с того времени из уважения к отцу-основтелю была принята догма, что Постгрес расширяемый. Без сарказма, я с эим согласен. Приведена таблица, что расширение индексных методов доступа появилось с версии 9.6, табличных с 12 версии, custom rmgr с 15 версии.
Был озвучен краеугольный вопрос:, а нужен ли гринплум? Скорее всего не нужен. И в том виде, в котором он сейчас есть он не был бы нужен, если бы Постгрес был расширяемым, то гринплан был бы расширением. Возможно сетлое будущее гринплума — стать расширением Постгреса. Для конситсентности экземпляров гринплама был бы полезен CSN (commit sequence number). Хейки пытался вкоммитить в 18 Постгрес, но хорошо, что не закоммитили и оставили в статусе WIP (work in progress), так как патч сырой. ВОзможно с 20–21 версии гринплум удастся оформить как расширение.
Дальше в докладе приводится пример вставки bloom-фильтрации в гринплум. С 14 версии Постгрес есть BRIN индекс с возможностью bloom фильтрации. Дальше были технические детали с аккуратными картинками, но из-за вскипания мозга я их не стал смореть.
Перейти с гринплума в cloudberry можно pg_dumpом, но из-за объемов это неприемлемо долго. В докладе описывается идея, что можно было бы это проделать утилитой pg_upgrade. Те, кто хранит террабайты в гринплум могут ждать появление способов миграции на что-то новое — Cloudbarry или другие форки гринплума. Возможно, дождутся.
В целом, я сделал вывод, что работа с кодом 9 версии Постгрес совсем не доставляет удовольствия, хорошо, что я не знаком с гринплумом. Доклад укрепил в намерении ещё тщательнее изучать Постгрес и не смотреть на гринплумы и прочие патрони.
Доклад: Как «выкопать» данные из нечитаемых таблиц?
Меня заинтересовал стиль докладчика, а также возможность расслабиться перед переходом к более сложным докладам. В докладе интересно послушать часть про пример использования утилиты pg_filedump. Если стиль не понравится, то доклад можно пропустить. Приведен простой блок на plpgsql, с помощью которого можно прочесть читаемые строки. В песочнице есть статья с кодом этого блока https://habr.com/ru/sandbox/241194/ По использованию pg_filedump есть статьи Александра Алексеева, они короткие.
Правильные моменты доклада: не лечить симптомы, а выяснить причину повреждений; лучше всего иметь правильно созданные бэкапы. Поправка: в 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. Многие доклады технически сложные и если начать слушать с них, то вряд ли удастся дойти до более простых докладов. Если описывать все доклады, то статья бы получилась длинная, ее было бы утомительно читать, да и технические доклады заслуживают отдельных статей.
