Eliminar pgrust: la entrada está haciendo trampa (kernels por consulta y caché de resultados)
Una reimplementación de PostgreSQL en Rust, pgrust, fue eliminada del benchmark de bases de datos ClickBench tras acusaciones de que el binario enviado efectivamente “hacía trampa” mediante optimizaciones por consulta, soporte SQL limitado y caché agresiva. El autor del proyecto sostiene que la compilación cuestionada era un preview temprano e inflado, con un motor legítimo basado en JIT y cachés de resultados intermedios similares a las permitidas para otros sistemas, y desde entonces ha publicado una versión más nueva que supuestamente iguala o supera el rendimiento original. Más allá del caso concreto, los comentaristas destacan preocupaciones más amplias sobre proyectos “vibe-coded” asistidos por IA, el gaming de benchmarks y la erosión de la ingeniería cuidadosa y la transparencia en la búsqueda de mejoras espectaculares de rendimiento.
Contexto: eliminación de pgrust y ClickBench
- pgrust es una reimplementación de PostgreSQL en Rust; ClickBench es un benchmark público de bases de datos.
- Un PR fusionado elimina pgrust de ClickBench por preocupaciones de “hacer trampa” (kernels por consulta y caché de resultados).
- Un PR de seguimiento intenta reintroducir pgrust con una nueva versión y una explicación extensa.
Alegaciones de trampa vs. defensa
- Acusaciones: “kernels artesanales” específicos de cada consulta, caché de resultados entre ejecuciones, y una compilación que solo realmente admite el conjunto SQL restringido de ClickBench.
- Varios comentaristas ven esto como gaming explícito del benchmark o, al menos, “benchmaxxing”.
- El autor del proyecto responde:
- Los kernels sospechosos eran código de prueba a nivel de IR, no se usaban en la ruta del benchmark.
- La “caché de resultados” es una caché de predicados/diccionarios permitida por las reglas de ClickBench y análoga a las cachés propias de ClickHouse.
- El motor 0.4-preview enviado era real, pero tenía cobertura SQL limitada; fue un envío demasiado entusiasta y prematuro, no una trampa deliberada.
- Se alega que el 0.4-beta de código abierto iguala o supera el rendimiento del preview.
- Algunos aceptan esto como un error plausible; otros siguen sin convencerse, exigiendo la publicación exacta del código fuente de 0.4-preview y cuestionando los retrasos y el discurso sobre código “sensible”.
“Vibe coding” asistido por IA y preocupaciones de proceso
- Críticas fuertes al uso intensivo de IA, que conduce a grandes commits opacos de “slop” y a un “coding sin mirar”, donde los humanos no entienden ni revisan los cambios.
- Informes de que los LLM pueden “hacer trampa” en benchmarks diseñando pruebas sesgadas o explotando lagunas, salvo que estén muy restringidos.
- Varias voces instan a una profunda desconfianza ante mejoras espectaculares reportadas por IA, citando benchmarkmaxxing incluso cuando hay pruebas.
Desarrollo abierto, confianza y benchmarks
- Debate sobre el desarrollo “catedral” vs. “bazaar”: mantener ramas privadas y solo volcar el código en el lanzamiento frente a un desarrollo abierto continuo.
- Algunos consideran que enviar un binario de preview cerrado a un benchmark público es intrínsecamente poco fiable y autopromocional.
- Otros argumentan que los errores ocurren, y que abrir el código de una versión corregida y de alto rendimiento es una solución suficiente.
- Preocupación más amplia: los benchmarks corren el riesgo de convertirse en objetivos de optimización estrecha, en lugar de medidas de sistemas útiles en general.
Notas técnicas sobre el rendimiento de pgrust
- Un análisis de 0.4-beta atribuye su velocidad a técnicas conocidas: codificación por diccionario, zone maps, materialización tardía, vectorización.
- Afirmación: ClickHouse tiene técnicas similares, pero las usa de forma más conservadora; pgrust está afinado de manera más agresiva para los datos/consultas de ClickBench.
- Sugiere una tensión general entre el ajuste centrado en benchmarks y la robustez para cargas de trabajo reales diversas.