SELECT item_id, COUNT(*) AS c
  FROM orders
  GROUP BY item_id
  ORDER BY c DESC
  LIMIT 10;

> We clarified with the author - while the binary had signs of optimization for specific benchmark queries, we have a reason to believe that the actual runtime didn't use per-query kernels... The usage of a query condition cache and cached statistics per granule is legitimate. The submission of a closed source preview version fine-tuned for benchmark was shady nevertheless. However, the new submission #2751 should move us post all the concerns.

Submitting an incomplete, closed-source preview build was a mistake on my part. Since then, we open-sourced a new version with full SQL support, ClickHouse merged it back into ClickBench, and the new version actually runs 7% faster (geomean) than the preview build that was removed.

[0] https://github.com/ClickHouse/ClickBench/pull/2165

For the other two claims in the removal PR, we wrote scripts you can use to verify the behavior of the original 0.4-preview binary:

  - Per-query kernels did not serve the benchmark queries[0]
  - The preview's fast repeat LIKE queries came from a dictionary filter cache, not a cached query result[1]

Across all queries and instance sizes on ClickBench, 0.4-beta is ~7% faster overall than the 0.4-preview binary that was removed. If 0.4-preview's numbers had come from hardcoded kernels or faked results, the open-source general engine wouldn't be beating it

[0] https://pgrust.com/downloads/archive/2026-09-clickbench-snap...

[1] https://pgrust.com/downloads/archive/2026-09-clickbench-snap...

[2] https://benchmark.clickhouse.com/

[3] https://github.com/ClickHouse/ClickBench/pull/2751

My first handful of blog posts were all about doing really cool stuff in Lisp: https://malisper.me/building-fizzbuzz-fractran-bottom/

Given everything happening with Black October[0], don't you think regulating models may be reasonable?

[0] https://en.wikipedia.org/wiki/Black_October_(information_sec...

To give you a sense of how fast it is, pgrust on a c6a.2xl is faster than ClickHouse running on a c6a.metal, a machine with 24x as many cores and costs 24x as much.

Edit: And now it's been accepted: https://benchmark.clickhouse.com/

[0] https://github.com/ClickHouse/ClickBench/commit/56535d29e825...

[1] https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2...

[0] https://github.com/ClickHouse/ClickBench/commit/56535d29e825...

[1] https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2...

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

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 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

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

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

fwiw, I wouldn't say working at the assembly level solves the problem. You now need to make sure that your definition of the assembly behavior is correct

Right now, I wrote a compiler that takes C and Rust code and compiles it to Lean. Then I have an LLM write a proof that the C and Rust code behave identically. I've been able to prove equivalent behavior for about ~70k lines of C code with pgrust.

The issue I've started to encounter is that the context needed for each incremental proof has kept growing, and things have slowed down dramatically. My hunch is that the speed is the time it takes to prove a line of code is on the order of O(n^2) of how much you've proved so far

I'm looking to see if there are ways to shard things so the required context scales better. Today I was going through the formal verification work Anthropic and Theorem published a few days ago, and it looks like they used some sort of orchestrator to manage all their proofs and ensure good clustering of similar code. I'm seeing if I can get an approach like that to work

It's just difficult enough that I think it's doable if done right. Half of me is debating if I should wait until the next model release because any improvement in model performance will help a ton

That example implements a linked list of integers. I'm curious how you would do a linked list of strings

Rust does a similar thing. When a function returns a value, a location for it will be put in the callers stack frame. That means it automatically stack-allocates values when feasible. The downside in Rust is you need to know the size of the value at compile time whereas Goose can do it for arbitrarily sized values

> Keys and values are fixed-size

so not quite what I'm looking for