PGConf.Russia 2025

Расскажу, какие трудности будут на вашем пути, если захотите реализовать новый TableAM. Что выбрать: Generic XLog или Custom RMGR? Зачем Custom SMGR? Как подключить постгресовые аллокаторы в стороннюю либу, даже если она этого вообще не поддерживает? Чего не хватает для колоночного движка (в том числе про векторизацию и позднюю материализацию) и как обойти ограничения?

Во второй части расскажу о внутренностях pgpro_tam — нового нативного табличного движка для OLAP, который поддерживает общепринятые форматы данных, различные SMGR, а если потребуется, то и сторонние планировщики и движки исполнения, находясь в рамках ACID. Всё это для получения самой быстрой аналитики на Postgres (не просто прикрутить DuckDB).

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

Небольшой доклад про различные расширения, которые помогут при оптимизации.

На одном из моих прошлых мест работы мы довели ElasticSearch до предела его возможностей. Нам потребовалась еще более масштабируемая альтернатива для системы с высокой нагрузкой на запись и редкими чтениями. Мы построили такую систему на PostgreSQL. Теперь многие из нас работают над ее преемником как над опенсорсным проектом.

Этот доклад расскажет о дизайне Bagger (названного в честь гигантских горнодобывающих машин), который способен управлять логами объёмом в десятки и сотни петабайт. Помимо обзора архитектуры, расскажем о причинах выбора решений и компромиссах, которые пришлось учитывать при проектировании.

Доклад не только продемонстрирует гибкость и мощность PostgreSQL, но и проиллюстрирует фундаментальные компромиссы, неизбежные при работе с большими данными.