zX41ZdbW

I have a similar project (which I created in 2024): https://adsb.exposed/

Among various datasets, it has OSM data (all of it): https://adsb.exposed/?dataset=OSM&zoom=4&lat=52.3756&lng=2.5...

And here are lighthouses: https://adsb.exposed/?dataset=OSM&zoom=3&lat=40.0444&lng=9.9...

lfalloc: https://github.com/ClickHouse/ClickHouse/pull/62826 hualloc: https://github.com/ClickHouse/ClickHouse/pull/31376

ClickHouse has been tested with jemalloc, mimalloc, tcmalloc (both variants), rpmalloc, lfalloc, hualloc, and ended up using jemalloc after a few patches and bug fixes.

Some of the oldest PRs could no longer be found.

For example, when I decided to continue my eight-year-old PR https://github.com/ClickHouse/ClickHouse/pull/104948, I couldn't see it - neither in search nor while navigating through pages.

Direct links still work.

Strange to see it here, the article is quite old.

Since pdqsort, vqsort, and glide sort, the current state-of-the-art are driftsort and ipnsort.

I've integrated them into ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/106650

I'm interested. milovidov@clickhouse.com

Maybe share my old article with Haiku developers: https://clickhouse.com/blog/agentic-coding

Could be a small chance, but it has already made many engineers reconsider their AI stance.

I've also built a visualizer into ClickHouse, so we can analyze its binary: https://play.clickhouse.com/binary?user=binary - which code takes more space, what dependencies are too big, or what template instantiations are bloated.

ClickHouse can read and visualize its own binary: https://play.clickhouse.com/binary?user=binary

It is useful to understand which dependencies, libraries, and template instantiations contribute to the size.

Let's add it to ClickBench: https://github.com/ClickHouse/ClickBench/

If you are interested in the AIS (ship telemetry) data, my team has created a visualization project: https://adsb.exposed/?dataset=Ships&zoom=5&lat=52.3890&lng=4...

This is one of the optimizations from ClickHouse - detect ASCII and go a fast path: https://github.com/ClickHouse/ClickHouse/blob/6cde32de1a2463...

All databases are hosted in VMs. Most of them only support amd64, so the host machine is also amd64 - this is the only limitation. It uses hardware virtualization, so nothing is emulated.

Thanks! There is a write-up: https://clickhouse.com/blog/clickbench-playground A lot of interesting things around hosting it.

Thank you for Ninja!

The speed (reading the build.ninja file) was never a concern for us. If I could share a wish-list, it will be:

- Fix the possibility of a segmentation fault when the build file is damaged;

- Use a better order of execution: https://github.com/ninja-build/ninja/issues/2157

Interesting, how does it compare with StringZilla? It has highly optimized case-fold and case-insensitive Unicode search kernels as well: https://github.com/ashvardanian/Stringzilla

Thanks, merged!

You should submit it to ClickBench for verification.

Someone ported it to ClickHouse: https://slach.github.io/CHSimCity/

Though it looks much simpler - fewer moving parts.

As a coincidence, I've just integrated Cesium into my data analytics tool two days ago, https://adsb.exposed/ Though the 3D mode gives a little bit worse image quality, so I keep 2D with Leaflet as the default.

ALP has been successfully integrated into ClickHouse: https://presentations.clickhouse.com/2026-release-26.3/, though the range of scenarios when it is reasonable to choose ALP over general-purpose compression is not so large.

Yes, for example, the datasets at this page: https://adsb.exposed/ are indexed by the Morton curve: https://github.com/ClickHouse/adsb.exposed/#database-and-que... and https://reversedns.space/ as well.

Also, a trivial application is image compression. Let's say you have a PNG image. PNG uses zlib, so if instead you take a raw bitmap and compress it with ZSTD, it typically will be better, but if you also sort pixels by the Hilbert curve first and then compress with ZSTD, it will be typically even better.

I tried pgrust on ClickBench recently, but it didn't work at all: https://github.com/ClickHouse/ClickBench/pull/983#issuecomme...

I tried pgrust on ClickBench recently, but it didn't work at all: https://github.com/ClickHouse/ClickBench/pull/983#issuecomme...

This is exactly what we need! Will try: https://github.com/ClickHouse/ClickHouse/issues/108247

It will be nicer if the README focuses more on per-core performance.

About the actual algorithm - will something like matching in a perfect hash table help?

Why not a wildcard DNS pointing to a few Anycast IP addresses with proxies?

Yes, it was a typo. Thank you!

Just tested a few minutes ago on the ClickBench dataset. Overall quite good, but, depending on particular columns, most of the time slower - e.g., ~2.0 vs ~2.8 GB/sec on Graviton 4 machine in AWS.