prantogg opened a new pull request, #843: URL: https://github.com/apache/sedona-db/pull/843
## Summary PR #646 ([#250](https://github.com/apache/sedona-db/issues/250)) wired the file metadata cache through the GeoParquet wrapper's own `DFParquetMetadata` calls but not through the inner `ParquetOpener`'s `ParquetFileReaderFactory`. With the inner factory left at `DefaultParquetFileReaderFactory`, SQL queries against a registered view kept paying full `metadata_load_time` on every execution even with `datafusion.runtime.metadata_cache_limit` configured. Install `CachedParquetFileReaderFactory` on the inner `ParquetSource` in `GeoParquetFormat::create_physical_plan`, mirroring DataFusion's stock `ParquetFormat::create_physical_plan`. ## Test plan - New unit test asserts the inner `ParquetSource` has a custom factory after `create_physical_plan` — fails on `main`, passes here - `cargo test -p sedona-geoparquet --lib` → 61 passed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
