> 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

▲

what 36 minutes ago | parent | next [-]

The latest of the three commits in the repo:

> 413,963 files changed

> +2,908,538

> -3,423,007

How is anyone supposed to audit that? I doubt you’ve looked at even a small fraction of the code, if any. Especially since this commit is two days after the second. Pure vibes.

▲

anonymous908213 2 hours ago | parent | prev | 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 an hour 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

	▲	verdverm 10 minutes ago \| parent [-]
		> check the submitted 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)

▲

an hour ago | parent | prev [-]

[deleted]

▲

verdverm an hour 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 an hour 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 an hour 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. It's categorically slop or the opposite of quality and care in development.