Tune lakehouse queries

Inspect query diagnostics for bytes read, row groups touched, returned rows, planning time, and cache status. Record the source hashes and mapping IDs with each measurement so comparisons use the same data and mapping.

A selective query may read only some row groups when metadata and predicates permit pruning. A broad aggregate can still require substantial source work even when it returns a single row.

Project only the fields the application needs. Apply the question’s valid filters, and ensure mapped keys have the expected type and direction. Investigate null or dirty keys before building larger mappings; a fast result over an incorrect join is still incorrect.

Keep Parquet metadata and source manifests current. After refreshing a source, check whether query artifacts and mappings remain compatible with its new version.

Result caching and prepared execution can reduce repeated work for eligible queries. Other optional settings affect filtering, execution scheduling, or reusable indexes. Their defaults are listed in Configuration and source management.

Enable one setting at a time in a test deployment. Compare completed requests, result values, memory, median latency, and tail latency under the same concurrency and cache conditions. A shadow setting records a proposed choice while retaining the existing execution behavior.

Use the baseline when an optional setting increases work or produces no useful improvement for your workload. Improve query performance provides the broader query-measurement procedure.