Comment by malisper
7 hours ago
> I've seen his explanation. I don't find it convincing, at all
You don't have to take my word for it. If you want you can inspect the binary yourself: https://pgrust.com/downloads/archive/2026-09-clickbench-snap...
You can run the binary with PGRUST_GRAVITY_REPORT=1 which logs the code path hit for every query. You'll see that all the code goes through the general query path. We did have hand-rolled code in the binary, but we used it for testing. The code is not used when running the benchmark. We also did not use a results cache. Warm runs still scan all the data. You can verify all of this
You are right, though, that it did support a narrow set of SQL. It supported scans, group bys, sorts, and filters. That's enough to run all the queries on ClickBench, but failed on functionality not tested by the benchmark like subqueries
> you can inspect the binary
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
(copied and pasted from another place you gave this unsatisfactory answer)
If you don't trust the logging, here's a script you can run that instruments the binary and shows that the files called out for cheating don't run during the benchmark: https://pgrust.com/downloads/archive/2026-09-clickbench-snap...
It instruments the files that were called out in the PR, then runs ClickBench. You can run it and see that the code in those files doesn't run.
If you can find anything suspicious in the binary, let me know, and I'm happy to dig in
release the full commit history please, your deflections are tiresome
this would be less dramaful if you had said something more like "claude cheated and we didn't notice, here's what we will be doing going forward..."
people empathize more with those who admit mistakes than those who try to argue around them