| ▲ | Vaushite 2 hours ago |
| Behind the link "slow software that the creator is claiming is fast" is the following text: "funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved)" This aged like milk. pgrust was caught cheating on all benchmarks this week. |
|
| ▲ | malisper 2 hours ago | parent | next [-] |
| > This aged like milk. pgrust was caught cheating on all benchmarks this week. Can you back this up? Our code is open source here[0]. You're free to audit it and benchmark it as much as you want. You'll find it's just as fast as we claim it is [0] https://github.com/malisper/pgrust |
| |
| ▲ | anonymous908213 2 hours ago | parent | next [-] | | Where's the source code for the version that was already caught cheating? Prompting Claude to remove the evidence of cheating and then publishing that doesn't undo the cheating. | | |
| ▲ | malisper 27 minutes ago | parent | next [-] | | Fair point: the 0.4-beta source doesn't prove anything about the benchmarked binary. So don't take my word for it or rely on the source we published as evidence. Instead, check the submitted binary itself: https://pgrust.com/downloads/archive/2026-09-clickbench-snap... If you run it with PGRUST_GRAVITY_REPORT=1 it will report the code path hit for each query. You can see that all the queries go through the general query engine The binary does contain hand-written kernels in the irprobe files. These were used for testing. You can validate that when running the benchmark, those files are dead code The engine supports a narrow subset of SQL: scans, group-bys, filters, and sorting. That's enough to run ClickBench. It doesn't support e.g. subqueries which is why some of the follow up queries failed | |
| ▲ | 32 minutes ago | parent | prev [-] | | [deleted] |
| |
| ▲ | verdverm 40 minutes ago | parent | prev [-] | | we don't have the commits we need to audit the first commit has 400k files, the other two more than 1000 each, if you are going to ask others to audit this scale of ai generated code, can you tell us what you have done to audit it? What I have seen is your Ai adding a lint test to make sure it doesn't cheat again. Are you personally aware of this file? How can you ensure it doesn't alter it and reinject the hand rolled benchmark queries? Will you be reviewing changes more thoroughly going forward? https://github.com/malisper/pgrust/blob/38634b408dea373f3944... transparency is the way to end the controversy, which appears to be sharing the full commit history based on HN responses For clarity, I do not think you personally cheated or did anything nefarious. This is more another example in the "too much eyes free coding" columnar database. | | |
| ▲ | malisper 16 minutes ago | parent [-] | | Unfortunately, we have some sensitive stuff in our internal repo that we can't share. Fortunately, you can check the binary we submitted yourself: https://pgrust.com/downloads/archive/2026-09-clickbench-snap... You can run it with PGRUST_GRAVITY_REPORT=1 and it will log the codepath that was hit for every query On the lint, yes, I'm aware. It's one layer of defense. When we were prepping for the 0.4-beta release, we generated a large number of fresh queries and made sure the engine runs them and performs well across all of them | | |
| ▲ | verdverm 6 minutes ago | parent [-] | | > you can check 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 > It's one layer of defense. Needing to put in tests to make sure the Ai doesn't cheat is an interesting development in software development. I personally see it as a big red flag and evidence the machines are not going to replace human developers any time soon, if ever. |
|
|
|
|
| ▲ | hitekker an hour ago | parent | prev | next [-] |
| For those curious, see the accusation here https://github.com/ClickHouse/ClickBench/pull/2165 and then the HN thread https://news.ycombinator.com/item?id=50205816 HN is waiting for the source code for pgrust 0.4-preview to be released, the version which allegedly cheated Clickhouse benchmark. So far, the people (person?) behind pgrust has not committed to releasing the offending code, and has instead offered other code (0.4-beta, not preview). |
|
| ▲ | anematode 2 hours ago | parent | prev [-] |
| The author claimed that it was an honest mistake, but looking closer at the original PR removing it, his explanation doesn't make sense. Maybe what's happened is that their bots reward hacked their way into special-casing the benchmarks without a proper audit from the humans involved, and now they're doing vibed damage control.... |
| |
| ▲ | verdverm 42 minutes ago | parent [-] | | This is almost certainly what happened. The first commit has 400k+ files, there is no way one person audited that. The project has tell tale signs of eyes free coding and ralph-like loops. |
|
