pgrust обогнал ClickHouse в его же бенчмарке — до 3 раз

> Обычно, когда инженеры пытаются ускорить программное обеспечение, они работают снизу вверх. Они запускают бенчмарк, смотрят на флеймграф, находят горячую точку и пытаются ускорить свой код на 15% или 20%. Проблема подхода снизу вверх в том, что вы не знаете, каков потолок. Вы можете быть в 20% от самого быстрого возможного кода, который может выполнить железо, а можете быть в 100 раз дальше.

> Когда мы начали создавать Gravity, мы перевернули этот вопрос. Мы спросили себя: насколько быстро база данных может работать на самом деле? Вместо того чтобы постепенно ускорять наш существующий движок запросов, мы хотели начать с физического предела скорости нашего оборудования и формата файлов и двигаться в обратном направлении. Мне нравится называть это «программированием на скорости света».

То, что описывается как «обычный» подход к оптимизации кода, на самом деле скорее «наивный» подход. Любая серьёзная работа по оптимизации производительности следовала бы подходу, при котором сначала определяется, каков потолок, допускаемый оборудованием, и проводится бенчмарк относительно него. И это было верно ещё до LLM.

См., например: https://www.marginalia.nu/log/a_106_native_calls/

Извиняюсь за придирки, но я почувствовал, что другим читателям может быть полезно понять контекст: эта часть подхода не нова. Их использование Claude для генерации этих оптимизированных бенчмарков уже достаточно интересно, так что я не чувствую необходимости привлекать дополнительное внимание к этой части в их статье.