3 
Содержание
Автор интегрировал колоночный движок MergeTree напрямую в PostgreSQL через table access method. Table access method — это интерфейс PostgreSQL, который позволяет подменять способ хранения и чтения данных в таблицах без изменения ядра СУБД. Решение работает на ванильном ядре 19 версии и отдаёт данные сразу векторизованному исполнителю. Векторизованный исполнитель обрабатывает данные батчами, а не по строкам, что снижает накладные расходы на пересылку информации между операторами запроса. Это позволило сократить среднее время запросов ClickBench с 715 мс до 49 мс, сохранив при этом JOIN, ACID и привычную экосистему PostgreSQL. Для команд, решающих, стоит ли внедрять подобное расширение, важно понимать, что решение сохраняет все стандартные возможности PostgreSQL по транзакциям и соединениям, но ориентировано прежде всего на аналитические нагрузки.
Проблема векторизации на обычном heap
Векторный исполнитель pg_vexec обрабатывает батчи по 1024 строки, но упирается в доступ к данным. Heap — это стандартный построчный механизм хранения PostgreSQL — отдаёт строки по одной через слот, не принимает список колонок и не умеет пропускать ненужные страницы. На запросах ClickBench разбор широких строк занимал до 86 % времени, копирование страниц — ещё 26-47 %. Даже после добавления ORCA и векторных узлов VecHashJoin и VecAgg ускорение составило лишь 18-19 %. ORCA — это расширенный планировщик запросов, который лучше учитывает стоимость векторных операций. Профилирование показало, что ядра функций тратили меньше 2 % времени: узким местом оставался сам доступ к страницам. При принятии решения о переходе важно учитывать, что если запросы в основном читают много колонок из широких таблиц, то именно слой доступа к данным становится главным тормозом, а не сами вычисления.
Как перенесли MergeTree
MergeTree реализовали как tableAM без изменения ядра PostgreSQL. MergeTree — это колоночный движок хранения из ClickHouse, который сжимает данные по колонкам и позволяет читать только нужные поля. Движок хранит данные по колонкам и отдаёт их сразу в колоночном виде. В сочетании с pg_vexec первая версия снизила геометрическое среднее с 715 мс до 148 мс. Дальше устраняли мелкие узкие места: добавили SSE2 для сравнений, поправили обработку TargetEntry в VecHashJoin и настроили планировщик, чтобы VecSort корректно оценивал стоимость. В итоге запросы с ORDER BY и LIMIT ускорились в 30 раз, а среднее время на ClickBench упало до 49 мс. Для оценки целесообразности важно, что прирост достигается именно на аналитических запросах с фильтрацией по небольшому числу колонок; если нагрузка смешанная, выигрыш может быть меньше.
Ограничения и компромиссы решения
Движок пока не поддерживает все типы обновлений и требует отдельной настройки сжатия и партиционирования. Партиционирование позволяет разбивать данные по диапазонам или спискам значений, чтобы ускорить чтение только нужных частей таблицы. Планировщик ORCA иногда неверно оценивает стоимость векторных узлов, поэтому приходится использовать режим force. Полноценная работа с широкими таблицами (более 100 колонок) возможна только при запросах, где выбирается небольшая часть полей. Если нужны частые обновления отдельных строк, heap остаётся предпочтительнее. При решении о внедрении следует проверить, насколько часто в проекте встречаются точечные обновления и deletes: в таких сценариях колоночный движок может потребовать дополнительных доработок или гибридного использования с обычными таблицами.
Как это выглядит в российских проектах
В контурах без доступа к SaaS-версиям ClickHouse и с жёсткими требованиями к JOIN и транзакциям решение даёт возможность оставить одну платформу. Команды, уже использующие расширения Citus или Hydra, могут добавить MergeTree как ещё один tableAM и постепенно переносить аналитические запросы. Citus обеспечивает горизонтальное масштабирование PostgreSQL, а Hydra добавляет колоночные возможности. При этом сохраняется совместимость с существующими инструментами мониторинга и бэкапа PostgreSQL. Главный риск — необходимость самостоятельно собирать и тестировать расширение под конкретную версию ядра. Для российских команд это означает дополнительные усилия по поддержке, особенно если требуется сертификация или работа в изолированных контурах без внешних репозиториев.
Источник
Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: PostgreSQL добавил MergeTree из ClickHouse без форка ядра.
Курс по теме — Построение DWH на ClickHouse
