Вышла версия 0.2 pgrust — расширения Postgres, написанного на Rust. Релиз посвятили производительности: pgrust стал в 10 раз быстрее своей предыдущей версии. По сравнению с самим Postgres, на OLTP-бенчмарках он обгоняет его на 30%. А на Clickbench, тесте Clickhouse для аналитических баз данных, pgrust оказывается в 300 раз быстрее Postgres — и даже обходит сам Clickhouse.
Главный источник рывка — новый query engine. Он дал примерно 10x из этих 300x. Автор объясняет, почему у Postgres вообще есть такой запас для улучшений. Postgres родом из 80-х, когда главным узким местом был диск. С тех пор всё изменилось: данные часто целиком помещаются в RAM, аналитика массово читает данные и упирается в CPU или память, а NVMe в сотни раз быстрее старых жестких дисков. Поэтому теперь важнее скорость процессора и памяти.
Чтобы показать, насколько медленный движок Postgres, автор берёт простой запрос: сложить первые 500 миллионов чисел из таблицы. У Postgres это занимает около 20 секунд. Эквивалентный цикл на Rust — 358 миллисекунд, то есть примерно в 55 раз быстрее. Разница не совсем честная: в Postgres происходит больше работы, но суть оптимизации как раз в том, чтобы убрать лишние накладные расходы.
Дальше автор собирает миниатюрную копию движка Postgres. Классический подход называется Volcano model: каждый узел плана запроса отдаёт по одной строке через метод next(). Это просто, но дорого. Мини-версия Volcano на тех же данных работает 1.3 секунды. Первая оптимизация — батчинг: обрабатывать по 1024 строки за раз, а не по одной. Время падает до 480ms. Батч-буфер лежит на стеке, так что агрегация не делает лишних аллокаций памяти. Дальше помогает operator fusion — склейка узлов, когда заранее известно, что они часто работают вместе. Это даёт 358ms — ровно столько же, сколько обычный цикл на Rust. Но это читерство, заточенное под конкретный запрос. Универсальное решение — JIT-компиляция, которая генерирует идеальный код для любого запроса. О том, как pgrust использует JIT, автор обещает рассказать в следующий раз.
Последняя оптимизация — SIMD: CPU выполняет одну операцию сразу над несколькими числами. Так время падает до 135ms — почти в три раза быстрее обычного for-цикла. Компиляторы обычно не применяют SIMD к числам с плавающей точкой, потому что порядок суммирования влияет на результат.
Итого: три простых оптимизации ускорили запрос почти в 10 раз — с 1.3s до 135ms. Тесты гоняли на AWS c8g.4xlarge с Graviton4, PostgreSQL 18.4, параллельные запросы отключены. Поддержать проект можно звездой на GitHub; также есть Discord, список рассылки и сайт pgrust.com.