Explain the execution flow of a query against an Iceberg table?

Running a query against an Iceberg table moves through a defined sequence of metadata resolution steps before any actual data file is ever read, progressively narrowing down exactly which bytes need to be scanned.

The catalog resolves the current metadata file, which points to the current snapshot; the engine reads that snapshot's manifest list and uses its partition-level summary bounds to eliminate entire manifests that can't possibly contain matching data, without opening those manifests at all.

For the manifests that survive that first pruning pass, the engine reads their individual data file entries and uses each file's own column-level min/max statistics to eliminate individual files that can't match the query's filter, and only after both pruning stages does the engine actually open and scan the remaining Parquet (or other format) data files — meaning for a selective query against a well-partitioned table, the vast majority of the table's total files are never even opened, let alone fully read.