Explain the internal working of manifest-level partition pruning?

Manifest-level pruning eliminates entire manifest files from consideration during query planning, using only the summary statistics stored in the manifest list, without ever opening the eliminated manifests to inspect their individual data file entries.

When Iceberg writes a manifest file, it computes and records the aggregate partition-value bounds (minimum and maximum) across every data file that manifest references; the manifest list then stores these aggregate bounds alongside each manifest's own entry, effectively summarizing "this manifest covers partition values between X and Y" without needing to enumerate every individual file within it.

At query time, if a query's filter predicate is provably outside a given manifest's recorded partition bounds — for example, a query filtering for the year 2026 against a manifest whose bounds show it only covers 2024 data — the query planner can discard that entire manifest immediately, based purely on reading the (comparatively tiny) manifest list, which is a significant efficiency win on large tables where reading every individual manifest file just to check its contents would itself become a meaningful bottleneck at scale.