remywang
Flowers and grass: poet Bui Giang
What makes pgrust fast? There's no one single reason, but a combination of techniques like dictionary encoding [1], zone maps [2], late materialization [3], vectorization [4], and a gazillion others. It's not unlike all the countless optimization passes in a compiler.
None of the optimizations are groundbreaking - in fact, I could find a counterpart of every optimization I checked in ClickHouse as well! So why is CH still slower?
I believe the difference is in when they decide to apply each optimization. Unlike compiler optimizations which are usually beneficial, DB optimizations are highly data-dependent, and the query planner needs to turn them on an off based on data statistics. For example, CH is more conservative in applying dictionary encoding, and it basically doesn't get used at all for ClickBench.
Turning off dictionary-related optimizations in pgrust immediately made it 5x slower (from 3.8s to 20.4s on my machine), while ClickHouse takes a total of 15.0s.
This points to one important nuance in benchmarking - when all you target is one single benchmark, you can be more aggressive during query planning, as plans that work well for one query probably also work well for others, due to characteristics shared among queries/datasets. But when you build a system that needs to support millions of users, you have to be conservative with optimizations.
[1]: https://motherduck.com/glossary/dictionary-encoding/
[2]: https://motherduck.com/glossary/zone-map/
[3]: https://arrow.apache.org/blog/2025/12/11/parquet-late-materi...
[4]: https://clickhouse.com/resources/engineering/vectorized-quer...
To turn off dictionary-related optimizations in pgrust, I used the following setting:
SET pgrust.gravity_road_off = 'dict.entries,percode.table,percode.length,verdict.coderange,
code.carry,code.render,code.front_part,code.front_dense,code.front_light,code.sparse,
code.cut,code.heads,key.codeif,prefetch.fp,text.frame';In general, the spec must be human readable, and I believe to achieve that we must do away with SQL. Putting aside the thousands of pages of SQL standard, even the core subset has a gnarly semantics due to issues like nulls.
A simpler semantics is one of the main motivations behind Prela [1], and despite its simplicity, we now know it’s powerful enough to express thousands of queries in the wild [2], as well as run doom [3].
How do you verify this compiler is correct? To do that, I think you at least need a formal semantics for both C and Rust in Lean, both sound like Herculean efforts
Declaration by the People of Programming
SQLite has a list of sponsors right on the homepage https://www.sqlite.org/
They're trying to build a digital God and then enslave it
Can Jev Parse CSV?
But to answer your question, I do still care about software being maintained by someone who can make design decisions instead of just yielding control to bots who tend to produce mediocre designs.
Kurzgesagt makes some of the best explainer videos, and they spend most of their time writing the script, not making the animation: https://youtu.be/uFk0mgljtns?si=NCMxIYGUYY-BbQgB&t=75