perf: evaluate primitive predicates on encoded pages - #8661
Open
Xuanwo wants to merge 7 commits into
Open
Conversation
Contributor
There was a problem hiding this comment.
Both prior findings are fixed: nullable constants preserve null-filter semantics, and auto planning is now per fragment with a bounded full-evaluation fallback.
The published rejected-bitpacking benchmark predates that planner change. On its ten-fragment topology, current auto profiles 327,680 rows across 20 windows instead of 32,768 across two, so the reported +8.5% S3 rejection overhead is not evidence for this head. Re-run that guardrail workload before relying on its remote-overhead figure.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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.
Primitive filters on current structural data files are evaluated only after decoding the predicate column to Arrow. For selective filters, this spends CPU and memory materializing values that only need a boolean result, and can read substantially more payload data than the result requires.
This PR evaluates supported
i32/u32comparisons directly on Constant, RLE, and bitpacked pages. The defaultautomode makes its cost decision independently for each fragment from the encoding type, sampled selectivity, selected range count, and predicted read amplification. Full evaluation stops and retains the ordinary filter when it exceeds either the encoding-specific amplification threshold or 4,096 ranges. Unsupported or unfavorable cases also retain the existing fallback, and Constant outcomes only short-circuit when metadata and nullability make the result exact.Benchmark
Measured on AWS EC2
c7i.4xlargewith arelease-with-debugbuild and a 10M-row dataset split across 10 data files. Each variant runs the same user-level scan: project the payload columns, apply the primitive filter, and consume all output batches. Each workload used two opposite-order blocks per mode (ABBAfor local filesystem andBAABfor S3), with six iterations per block. The first iteration of each block was discarded, leaving 10 warm samples per mode; the table reports their median.autoautoThe rejected S3 workloads show the bounded cost of making the safety decision per fragment: profiling adds requests even though the ordinary filter is ultimately retained. The accepted selective workloads still reduce both end-to-end latency and bytes read substantially.
The measured library/runtime contents match PR head
1140cac9d0. The private benchmark implementation commit is00c4018a5c; benchmark runner and summarizer provenance isf089a32876. Raw results and the harness remain in the private benchmark project.