duckdb: don't use tokio for local reads (#9175)

Compat:: while creating a filesystem makes duckdb integration use
Tokio. Tokio is bad on 64/128 core machines because it spawns every read
into a blocking pool. On 128 core contention eats 48% of runtime

Signed-off-by: Mikhail Kot <mikhail@spiraldb.com>

Author: myrrc

vortex-duckdb/src/multi_file.rs

@@ -29,6 +29,12 @@ use crate::duckdb::ExtractedValue;
 static REGISTRY: LazyLock<Registry> = LazyLock::new(Registry::new);
 
 fn resolve_filesystem(base_url: &Url) -> VortexResult<FileSystemRef> {
+    // Compat makes us use tokio which is very bad for local reads on
+    // high-core machines because reads go into blocking pool
+    if base_url.scheme() == "file" {
+        return Ok(Arc::new(ObjectStoreFileSystem::local(RUNTIME.handle())));
+    }
+
     // `base_url` has its path cleared by the caller, so the resolved path is empty and only the
     // store matters here. Going through the shared registry means DuckDB resolves the same set of
     // schemes as the Python and Java bindings, including the OpenDAL-backed ones when the