Run the geospatial benchmarks on every ADBC database

[alxmrs]

Summary

Runs the geospatial benchmark cases (benchmarks/geospatial) on every ADBC database against real data (ARCO-ERA5 and WeatherBench 2): daily, by hand, and on PRs that touch this layer. Each case checks its SQL answer against an xarray reference, so a green cell means that database computed the right numbers through xarray-sql's register → SQL → to_dataset path.

Results

Latest run (36318725813): 11 databases, 53 cells, all matching the reference. Times are the SQL step, including ingest.

Database	climatology	zonal mean	anomaly	forecast skill	zonal vector
DuckDB	✅ 2s	✅ 3s	✅ 2s	✅ 3s	✅ 4s
DataFusion	✅ 2s	✅ 1s	✅ 2s	✅ 2s	✅ 1s
GizmoSQL (Flight SQL)	✅ 2s	✅ 3s	✅ 2s	✅ 3s	✅ 4s
chDB	✅ 2s	✅ 3s	✅ 2s	✅ 3s	✅ 5s
ClickHouse 26.8	✅ 1s	✅ 2s	✅ 1s	✅ 2s	✅ 80s
PostgreSQL 18	✅ 3s	✅ 16s	✅ 4s	✅ 7s	✅ 16s
SQLite	✅ 7s	✅ 83s	✅ 23s	✅ 16s	✅ 80s
SQL Server 2022	✅ 7s	✅ 80s	✅ 34s	✅ 13s	✅ 40s
MySQL 8.4	✅ 22s	✅ 188s	✅ 24s	✅ 41s	✅ 188s
MariaDB 11.4	✅ 12s	✅ 66s	✅ 32s	✅ 89s	✅ 64s
Trino 483	✅ 203s	not run	✅ 206s	✅ 1578s	not run

Trino runs the regional cases only. Its driver ingests about 10k rows/s, so the two global-day cases (25M rows each) can't finish in a job. Case 01 (a 100M+ pixel Sentinel-2 scene) is too large to copy into a database per run, and 07–09 need DataFusion UDFs or Earth Engine; all of those stay n/a, as for the other non-DataFusion engines.

How

• GEOBENCH_ENGINE=adbc-<backend> runs a case on any backend in the ADBC tests' table (tests/_adbc.py), connected the same way.
• Windowed ingest. Registration copies data, and the cases open the whole archive, so each query ingests only the variables it names over the window its parameters bound.
• Dialect rewrites live only in the harness (_engines._ADBC), since xarray-sql translates data, not queries:
  • date_part('hour', …), timestamp literals, DOUBLE, MySQL backticks;
  • time + <duration>, keyed to how the adapter stores durations: integer nanoseconds (SQLite datetime(), ClickHouse addNanoseconds, SQL Server DATEADD) or text (MySQL/MariaDB DATE_ADD, Trino parse_duration);
  • MariaDB gets hash joins (join_cache_level = 8).
• Result normalization: interval, text and integer durations, and zone-aware times, are converted before comparing with the reference.
• Workflow geospatial-adbc.yml: one parallel job per database, each starting only its own server. Trino runs from a step with a 10 GB heap and a 3 GB memory catalog. Results go in the job summary and an artifact.

Found along the way

Fixed in #255:

• PostgreSQL had no statistics on freshly ingested tables, so the planner guessed and joins ran for over 10 minutes; the adapter now ANALYZEs (5 s and 14 s).
• SQLite missed rows at inclusive time bounds.
• The spilled read failed on mixed whole and fractional-second SQLite times.

Fixed in #261 (against main): the chunked round-trip lost windows over nanosecond times.

Documented in #255:

• MariaDB joins by nested loop unless hash joins are enabled.
• Trino's ingest rate and memory-catalog cap.

Tried and dropped: raising Trino's statement size (adbc.statement.ingest.max_query_size_bytes and query.max-length at 16 MB) made its ingest slower (277 s vs 203 s on case 02) and ran it out of heap. Turning rows into SQL text and parsing it is the bottleneck, not per-query overhead.

Fixed here: engine_suite.py --local ignored --cell-timeout (every case ran under a 600 s default), and the summary table now lists whichever engines ran.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AMTHTEAoyKzUJLvFmg5G6t