Gravity, el motor de consultas de pgrust, supera a ClickHouse hasta 3 veces en su propio benchmark

> Normalmente, cuando los ingenieros intentan hacer el software más rápido, trabajan de abajo hacia arriba. Ejecutan un benchmark, miran un flamegraph, encuentran un hotspot y descubren cómo acelerar su código un 15% o un 20%. El problema de trabajar de abajo hacia arriba es que no sabes cuál es el techo. Podrías estar a un 20% del código más rápido posible que el hardware puede ejecutar, o podrías estar a 100x de distancia.

> Cuando empezamos a construir Gravity, le dimos la vuelta a esta pregunta. Nos preguntamos: ¿qué tan rápido puede ser realmente una base de datos? En lugar de acelerar incrementalmente nuestro motor de consultas existente, quisimos partir del límite físico de velocidad de nuestro hardware y formato de archivo y trabajar hacia atrás. Me gusta llamar a esto “programar a la velocidad de la luz”.

Lo que se describe como el enfoque “normal” para optimizar código es en realidad más bien el enfoque “ingenuo”. Cualquier trabajo serio de optimización de rendimiento seguiría el enfoque de definir primero cuál es el techo que permite el hardware y hacer benchmarks contra eso. Y eso ya era cierto antes de los LLMs.

Ver por ejemplo: https://www.marginalia.nu/log/a_106_native_calls/

Disculpas por ser quisquilloso, pero sentí que podría ser útil para otros lectores contextualizar que esta parte del enfoque no es novedosa. Su uso de Claude para generar esos benchmarks optimizados ya es bastante interesante, así que no siento que sea necesario llamar la atención extra sobre esta parte en su artículo.