Мой PostgreSQL быстрее твоего и почти догнал ClickHouse

В сфере искусственного интеллекта произошло заметное событие. igor_suhorukov 50 минут назад Краткое содержание статьи Мой PostgreSQL быстрее твоего и почти догнал ClickHouse Простой 7 мин 1. 9K PostgreSQL * Open source * Базы данных * Big Data * Программирование * Мой знакомый - отличный архитектор, но полнейший сноб. У него в проде четыре разных базы данных.

PostgreSQL для OLTP, в ClickHouse у него лежат данные OpenTelemetry и веб аналитики, Elasticsearch для полнотекстового поиска в приложении, а MongoDB - “так исторически сложилось”. Между всем этим ETL, CDC вместе с дежурствами разработчиков в поисках где именно результаты не сходятся. Для него это все продуманная архитектура, а для меня излишняя сложностью в поддержке и разработке.

Технические детали

Недавно рассказал ему чем я занимался последнее время. – Мне удалось вставить табличный движок MergeTree из ClickHouse в PostgreSQL табличным методом доступа, на ванильное ядро СУБД без форка с доступом к нему из векторизованного исполнителя запросов. Просто возьми ClickHouse и не мучайся.

– Затем что мне нужны JOIN между множеством таблиц и согласованность данных в системе и одна привычная в разработке и поддержке платформа. Либо надежно, либо быстро! – А у меня получилось совместить лучшее из двух миров.

Векторизация уперлась в heap– Подожди. Ты же недавно портировал Greenplum в расширение для постгреса, а потом написал векторный исполнитель поверх него. MergeTree-то тебе зачем?

Отраслевые последствия

– Векторизация быстро молотит столбцы, но захлебывается в момент считывания данных. Предыстория этого началась когда я перенес Apache Cloudberry на PostgreSQL 19 в виде набора расширений и мне достался ORCA на PostgreSQL19 - стоимостный планировщик Greenplum. Сверху оптимизатора запросов разработал pg_vexec векторизованный исполнитель без единого патча ядра.

Его узлы VecScan, VecHashJoin, VecAgg и VecSort попадают в план запроса через штатные механизмы расширения СУБД и соревнуются с обычными узлами по стоимости. ORCA оценивает векторные узлы своей моделью стоимости. Внутри исполнитель обрабатывает батчи данных по 1024 строки в колоночном виде ядрами-вычислителями, привязанными к OID функции.

Если специального ядра нет, выражение вычисляет штатный интерпретатор выражений постгреса прямо внутри узла. Первый замер на ClickBench меня не порадовал, векторизация не сильно помогла в ускорении. На стандартном планировщике на heap pg_vexec уменьшил среднее геометрическое время выполнения запроса всего на 19% с 625 -> 506мс, а на ORCA на 18% с 1647 -> 1349мс.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.