How does DuckDB use zone maps and Parquet statistics to prune I/O?

Both DuckDB's own native storage format and Parquet files carry per-row-group statistics, typically minimum and maximum values for each column within that row group, which the query engine can compare against a query's filter conditions before ever reading the row group's actual data.

-- If a row group's stats show min(price)=50, max(price)=80,
-- and the filter is WHERE price > 100, DuckDB can skip that
-- row group entirely, since no row in it could possibly match.
SELECT * FROM products WHERE price > 100;

This comparison happens during query planning and execution, before any actual column data is decompressed or scanned, so a row group that's provably irrelevant to the filter never gets touched at all, saving both disk/network I/O and decompression CPU work. The effectiveness of this pruning depends heavily on data layout: data that's naturally sorted or clustered by a commonly-filtered column (like a date field in roughly chronological data) prunes extremely well, since entire row groups will often fall entirely outside a given filter's range, while data with no meaningful ordering on the filtered column prunes far less effectively, since most row groups will likely contain at least some matching values.