Query Latency Query latency is highly variable and depends on several factors:

Query Type: A simple SELECT with a WHERE clause on a single table will be much faster than a complex multi-table JOIN that requires shuffling data between workers.

Data Size: The total volume of data being scanned from disk or object storage is a primary driver of latency.

Execution Plan: The system chooses between different plans. A

- LocalExecutionPlan that runs on a single node is fastest. A

- DistributedBroadcastJoinPlan is used when one table is small and is generally faster than a DistributedShuffleJoinPlan, which is the fallback for large tables and tends to have the highest latency.

Fault Tolerance: If a worker node fails, the system will automatically retry the task up to a configured maximum, which can add to the total execution time.

Caching Yes, caching is a key feature! Your team's approach sounds very thorough. Our current implementation focuses on caching the final results of queries to avoid re-computation.

Here’s how it works:

In-Memory TTL Cache: We use a simple, time-to-live (TTL) in-memory cache for the /query endpoint. When a query is executed, a SHA256 hash of the SQL string and the requested format (e.g., "json" or "arrow") is used as the cache key.

Cache Check: For every incoming query, we first check the cache. If a valid, non-expired result is found, we return it immediately, which is significantly faster.

Cache Population: If it's a cache miss, the query is fully executed, and the final result is stored in the cache before being sent to the client. The TTL is configurable, defaulting to 300 seconds.

This approach caches the final output rather than lower-level data like file metadata or individual data blocks, but your point about caching Parquet metadata and S3 listings is excellent—that would be a great way to further optimize the planning phase.