Skip to content

fix(published): a table's extent and count from its manifests, not a scan of every file - #172

Merged
nhobin219 merged 1 commit into
mainfrom
fix/table-open-extent-from-manifests
Oct 20, 2026
Merged

nhobin219 merged 1 commit into
mainfrom
fix/table-open-extent-from-manifests

Conversation

@nhobin219

Copy link
Copy Markdown
Owner

The fix shipped on the 0.22 line as 0.22.1 (#171), for main. Table.open ran min/max/count(*) over iceberg_scan, reading every data file's footer on every snapshot open (553 files: 20+ s, minutes on a loaded box). The numbers now come from the manifests' per-file statistics, with the scan as fallback when a file lacks bounds or a delete file exists. Test pins equality with the scan and that open never issues it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXyESUWnfYF3jXPHp7pz12

…scan of every file

`Table.open` learned its extent with `min/max/count(*)` over `iceberg_scan`,
which reads every data file's footer: a request per file, on every open, of
every reader. A log that publishes every few minutes grows thousands of small
files, and one open took 20+ s from a laptop and minutes on a loaded box.

The three numbers are in the manifests' per-file statistics (record counts and
the offset column's bounds), one read of the manifest list and one per
manifest. Falls back to the scan when the statistics cannot answer exactly: a
file without bounds on the offset column, or a delete file.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXyESUWnfYF3jXPHp7pz12
@nhobin219
nhobin219 merged commit 7fe2886 into main Oct 20, 2026
6 checks passed
@nhobin219
nhobin219 deleted the fix/table-open-extent-from-manifests branch October 20, 2026 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant