Repository navigation
Conversation
On S3, a data GET to an object requested less than about a second earlier returns its headers roughly twice as fast as one to an object left untouched for ten seconds or more. On the deployed service the data GET header p50 is about 30-45 ms right after a footer read of the same file and 85-90 ms otherwise. A footer cache hit removes exactly that footer read, so warm scans pay the slow first touch on every file. With ICEBERG_PARQUET_PRE_TOUCH_MAX_IN_FLIGHT above 0 (default 0, off), a cache hit issues one 8-byte ranged GET of the file tail. Under file_stream_open_ahead the hit happens while the previous file is still being read, so the touch lands before that file's data reads. The touch never delays the hit: it is a task owned by the reader (aborted on drop), takes a slot of a process-wide semaphore without waiting, and is skipped when no slot is free. parquet_pre_touches and parquet_pre_touch_skipped count both cases. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
On S3, a data-range GET of an object that was requested less than about a second earlier gets its response headers roughly twice as fast as one to an object left untouched for ten seconds or more. Measured on the deployed SPCS service (TPC-H SF100, one run, one image):
A footer cache hit removes exactly the footer read that made the data read fast, so warm scans pay the slow first touch on every data file.
What
With
ICEBERG_PARQUET_PRE_TOUCH_MAX_IN_FLIGHTabove0(read once per process; default0, off), a footer cache hit issues one 8-byte ranged GET of the file's tail. Underfile_stream_open_aheadthe hit happens while the previous file is still being read, so the touch lands before that file's data reads start.SpawnedTaskowned by the reader (aborted when the reader drops; no detached task).parquet_pre_touchesandparquet_pre_touch_skipped; the cache init log gainspre_touch_max_in_flight.MetadataCache::loadbecomesload_reporting_hit, which also returns whether the footer came from the cache.Tests
cargo test -p datafusion_iceberg --lib parquet_metadata_cache: 27 passed (3 ignored benches), including four new tests:size-8..size, and counts it;cargo clippy -p datafusion_iceberg --all-targets: no warnings in the changed file.Stacked on #140. The engine measurement on SPCS follows with the knob on in a separate arm.
🤖 Generated with Claude Code