Find why a query reads so much
A query returns a few thousand rows but scans terabytes, or bills for far more data than it should. The cheapest speed-up is not reading data at all: skipping partitions, files and columns. Each skipping mechanism has a precondition, and one broken precondition switches it off silently. Which one is broken here?
You will end with the reason the query reads more than it needs, and the change that stops it.
Work in order of leverage, and stop at the first hit.
Diagnose
Is the filter usable, and on the partition or clustering column?
A column wrapped in a function or cast (WHERE year(ts) = 2026) switches off every mechanism on this page. Look at the scan node of the physical plan for the filters it actually received, not at the SQL. If the filter is wrapped: rewrite it on the bare column (ts >= '2026-01-01' AND ts < '2027-01-01').
Is the data clustered on that column?
If not: per-file min/max statistics prune nothing, however many you keep. An unsorted block of B values covers on average (B − 1) ÷ (B + 1) of the column's range: 99.98% for B = 10,000, so every block matches every query. Check files scanned, not bytes scanned, to see it. Sort or cluster the data on the column.
Is the filter negative?
If the selectivity comes from <> or NOT IN: no skipping mechanism helps, because nearly every block contains some non-matching value. You need a different physical design.
Does the selective filter exist only on the other side of a join?
orders JOIN customers WHERE customers.country = 'NZ' filters customers, not orders. If so: you need a runtime filter (dynamic pruning): build a filter from the small side's join keys and apply it to the big side's scan. Check whether your engine builds one, and whether the plan has a point where it can wait for it.
Is the projection narrow, in a columnar format?
Selecting few columns from a columnar file reads only those columns, including fields inside nested structures. Check bytes read, not the number of columns: one wide text column can dominate.
Can the answer come from metadata alone?
If the aggregate can be combined from per-file statistics (count, min, max) and the filter prunes whole files with nothing left to check row by row: the engine can answer from metadata without reading data. If any residual filter remains, it cannot.
Is there ORDER BY … LIMIT?
Confirm the plan uses a Top-N operator, not a full sort followed by a cut, and whether the current threshold feeds back into skipping files that cannot beat it.
Only then make execution faster
Once nothing more can be skipped, speed up the work that remains. See Speed up a reasonable plan. It is the smaller prize.