Query Acceleration

Query acceleration improves scan performance by changing how data is physically laid out, not by adding an index, a cache, or a proprietary format. Crunch profiles the queries that actually run against a table and chooses a layout strategy that minimizes the bytes those queries have to read.

On production workloads this delivers a 10–20% query speed improvement with no manual tuning, which translates directly into lower compute cost.

How it works

1. Query profiling — Crunch ingests query history from your engine to learn which columns are used as filters, which are used in joins, and how selective each predicate is. See Connect query history.
2. Data fingerprinting — Crunch analyzes cardinality, value distribution, and correlation between columns to understand how well each candidate layout would cluster the data.
3. Layout selection — Crunch chooses among sort order, Z-order or multi-dimensional clustering, target file size, and row group size for each table. Crunch then ranks tables by ROI and recommends the ones that will deliver the most impact.
4. Layout application — the chosen layout is applied during the next compaction pass and committed atomically, so acceleration costs no extra rewrite.

Users can choose not to ingest query history and instead select ordering strategies manually. In that case, Crunch simply orders your data according to your selection.

Layout strategies

• Sort order — best when queries filter on one dominant column, such as an event timestamp. Produces tight minimum and maximum statistics so the engine can skip most files.
• Z-order and multi-dimensional clustering — best when queries filter on several columns in varying combinations. Trades some per-column tightness for good pruning across all of them.
• File sizing — larger files reduce planning overhead; smaller files allow finer-grained pruning. Crunch picks the balance point from observed scan sizes.
• Row group sizing — controls the granularity at which a Parquet reader can skip data within a file.
• Stats — statistics such as Bloom filters and NDV, driven by query profiling, to accelerate query planning and execution.

Measure the result

The Granica Console reports, per table, the layout strategy in effect, the proportion of files pruned by recent queries, and the change in average bytes scanned since the strategy was applied. Use these metrics to confirm that the strategy matches your workload before you extend it to more tables.

See also