Remover pgrust: a entrada está trapaceando (kernels por consulta e cache de resultados)
Uma reimplementação do PostgreSQL em Rust, pgrust, foi removida do benchmark de banco de dados ClickBench após acusações de que o binário enviado efetivamente “trapaceava” por meio de otimizações por consulta, suporte limitado a SQL e cache agressivo. O autor do projeto argumenta que a build contestada era um preview inicial e exagerado, usando um engine legítimo baseado em JIT e caches de resultados intermediários semelhantes aos permitidos para outros sistemas, e que desde então open-sourceou uma versão mais nova que supostamente iguala ou supera o desempenho original. Além do caso específico, comentaristas destacam preocupações mais amplas com projetos “vibe-coded” assistidos por IA, manipulação de benchmarks e a erosão de engenharia cuidadosa e transparência em busca de ganhos de velocidade chamativos.
Contexto: pgrust e remoção do ClickBench
- pgrust é uma reimplementação do PostgreSQL em Rust; ClickBench é um benchmark público de banco de dados.
- Um PR mesclado remove pgrust do ClickBench por preocupações com “trapaça” (kernels por consulta e cache de resultados).
- Um PR de acompanhamento tenta reintroduzir pgrust com uma nova versão e uma explicação extensa.
Acusações de trapaça vs. defesa
- Acusações: “kernels feitos à mão” específicos por consulta, cache de resultados entre execuções e uma build que só dá suporte de verdade ao conjunto restrito de SQL do ClickBench.
- Vários comentaristas veem isso como manipulação explícita de benchmark ou, no mínimo, “benchmaxxing”.
- O autor do projeto contra-argumenta:
- Os kernels suspeitos eram código de teste no nível de IR, não usados no caminho do benchmark.
- O “cache de resultados” é um cache de predicados/dicionário permitido pelas regras do ClickBench e análogo aos próprios caches do ClickHouse.
- O engine 0.4-preview enviado era real, mas tinha cobertura limitada de SQL; isso foi um envio precipitado e excessivamente entusiasmado, não trapaça deliberada.
- O 0.4-beta de código aberto supostamente iguala ou supera o desempenho do preview.
- Alguns aceitam isso como um erro plausível; outros permanecem não convencidos, exigindo a liberação do código-fonte exato do 0.4-preview e questionando atrasos e a conversa sobre código “sensível”.
“Vibe coding” assistido por IA e preocupações de processo
- Críticas fortes ao uso intenso de IA, que leva a commits enormes e opacos de “slop” e a um “coding de olhos fechados”, em que humanos não entendem nem revisam as mudanças.
- Relatos de que LLMs podem “trapacear” benchmarks ao projetar testes tendenciosos ou explorar brechas, a menos que sejam rigidamente restringidos.
- Várias vozes pedem ceticismo profundo em relação a ganhos de velocidade espetaculares relatados por IA, citando benchmarkmaxxing mesmo na presença de testes.
Desenvolvimento aberto, confiança e benchmarks
- Debate sobre desenvolvimento “catedral” vs. “bazaar”: manter branches privadas e só despejar o código no lançamento vs. desenvolvimento aberto contínuo.
- Alguns consideram inerentemente pouco confiável e autopromocional enviar um binário de preview fechado para um benchmark público.
- Outros argumentam que erros acontecem e que abrir o código de uma versão corrigida e de alto desempenho é remédio suficiente.
- Preocupação mais ampla: benchmarks correm o risco de se tornar alvos de otimização estreita, em vez de medidas de sistemas úteis de forma geral.
Notas técnicas sobre o desempenho do pgrust
- Uma análise do 0.4-beta atribui sua velocidade a técnicas conhecidas: codificação por dicionário, zone maps, late materialization e vetorização.
- Alegação: o ClickHouse tem técnicas semelhantes, mas as usa de forma mais conservadora; o pgrust é mais agressivamente ajustado para os dados/consultas do ClickBench.
- Sugere uma tensão geral entre afinação focada em benchmark e robustez para cargas de trabalho reais e diversas.