Partition Pruning
The query planner skipping files whose partition values cannot satisfy the predicate, which is the single largest determinant of analytical query cost.
Analytical engines bill by data scanned. Pruning is how a query avoids reading most of the table: if the data is laid out by date and the query filters on a date range, only the matching directories are opened.
The design decision is which column to partition by, and the answer is the column
that appears in the WHERE clause of most queries — usually a date. The failure
modes sit either side of that.
Partition on something too granular, such as a timestamp to the second, and you get millions of tiny partitions; the planner spends longer listing metadata than reading data, and the small-file problem arrives with it. Partition on something too coarse, or on a column nobody filters by, and every query is a full scan regardless.
The trap that catches teams is a predicate the planner cannot use. Wrapping the partition column in a function, comparing it to a value of a different type, or filtering on a derived column all silently defeat pruning, and the query still returns the right answer — just at fifty times the cost. Reading the query plan rather than the result is the only way to catch it.