Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Tokio is a cooperative threadpool and has strong assumptions that tasks yield frequently. Running CPU-bound work on the same threadpool results in poor throughput and can lead to connections getting dropped.

Describe the solution you'd like

We should add a with_runtime option to ParquetObjectReader that takes a tokio handle and spawns all work to the provided runtime. This encourages decoupling CPU-bound query execution / parquet decoding, from cooperatively scheduled IO.

Describe alternatives you've considered

I'm aware of a number of codebases, such as InfluxDB IOx, that implement this spawning logic at the ObjectStore boundary instead.

Additional context

#4040 attempted to add something similar to object_store, but concluded this really belongs in the integrations

#5882 may be related to this