Status:

temporary fork dependency, so the target branch is not develop

Summary

A SpatialBench suite (Apache Sedona's geospatial ride-sharing benchmark) built on top of DataFusion. It runs Q1 four ways, {parquet, vortex} × {wkb, native}, to show where the speedup comes from.

• Query: Q1 — trips within a radius of a point, ranked by distance.
• Wired: the trip table + Q1; dimension tables and other queries are catalog-ready, not yet wired.
• Datasets: wkb.rs generates the canonical WKB base; native.rs derives the native encodings by decoding WKB → GeoArrow points in Arrow (geoarrow_cast, so Vortex carries no WKB code), writing a Vortex Point file and a GeoParquet file.
• Some glues.

Results (Q1, scale factor 1, release)

Why the others are slow

parquet-wkb (103 ms): the geometry is stored as raw WKB bytes, and the query wraps it in ST_GeomFromWKB(pickup). DataFusion pushes the radius filter down into the parquet reader as a row-filter, but to actually evaluate it the reader has to decode every WKB blob into a geometry and then call geodatafusion's ST_Distance UDF once per row. Both of those costs grow with the number of rows, which is why it's the slowest.

parquet-native (52 ms): GeoParquet stores the points natively as geoarrow.point, and skip_metadata=false keeps that extension so geodatafusion recognizes the column as a geometry, so the WKB-parsing cost disappears. But the distance is still computed by geodatafusion's per-row UDF: Parquet has no geo kernel inside the scan, so even with filter pushdown it still materializes the points into Arrow and dispatches the UDF row by row. Dropping the parse is why it beats parquet-wkb, but the per-row compute keeps it well behind Vortex.

vortex-wkb (46 ms): this is Vortex without the pushdown. The predicate can't lower into the scan because its operand is ST_GeomFromWKB(t_pickuploc), which the converter doesn't recognize as something it can translate, so the whole filter stays above the scan and geodatafusion computes it. The columnar format still reads faster than Parquet, but the geo work happens above the scan.

vortex-native (5.7 ms): both blockers are gone. With points=native the query drops the ST_GeomFromWKB wrapper, so the operand is just a plain Point column the converter can translate, and the column itself is the native Point extension that GeoDistance knows how to compute over. The distance is fused right into the scan and evaluated over the columnar x and y as they're read, with the filter applied in-scan, so there's no WKB parsing and no UDF round-trip, and only the handful of matching rows ever materialize.