Repository navigation
[improvement](be) Decode SNII zstd and raw .prx windows faster - #69770
Conversation
…r document ### What problem does this PR solve? Issue Number: None Related PR: apache#69649 Problem Summary: A phrase query decodes the positions of the selected documents of every .prx window it reads. For a zstd or raw window that is the plain payload: per document a count, then its position deltas, all varints. decode_payload_csr_selective made at least one out-of-line call that returns a Status for every document of the window, selected or not (get_varint32_fast, skip_varints, decode_delta_run). Timed per window on a 10M-row AgentLogs load, the plain decode was 11.7 us of the 18.6 us a zstd window costs; a PFOR window costs 1.4 us. The loop now keeps the cursor in a register and handles the usual cases inline: a single-byte count, walking past the deltas of a document that is not selected, and a run of single-byte deltas. Anything else -- a multi-byte value, a run that does not fit, a prefix sum that would overflow -- goes to the checked decoders from the same cursor, so they decide and report as before. The output vector grows as before; nothing is reserved up front. Hot phrase queries on data whose position windows are mostly zstd (10M rows, interleaved A/B in one process): 0.93x and 0.94x for the two most position-heavy queries, the others within noise. ### Release note None ### Check List (For Author) - Test: Unit Test (PrxPodTest.SelectivePlainDecodeMatchesInputForRandomWindows compares the decoded positions with the input for 300 random windows of mixed varint widths, raw and zstd) - Behavior changed: No - Does this need documentation: No Co-Authored-By: Claude Opus 5.5 <[email protected]>
…urce ### What problem does this PR solve? Issue Number: None Related PR: apache#69649 Problem Summary: Every zstd .prx window a query reads was decompressed with ZSTD_decompress, which creates and frees a decompression context (about 96 KB) per call, into a zero-filled vector that is also allocated per call. Timed per window on a 10M-row AgentLogs load, the decompression took 6.8 us with a context per call and 4.8 us with a reused one. ZstdDecompressor keeps one context, created at the first frame, and one output buffer that only grows and is not zero-filled (decompression writes every byte before it is read). SniiIndexSource owns one, and the cursors it opens pass it to the .prx decoder through PrxDecodeContext; the cursors of a source decode on its thread one window at a time, and the decoded plain payload is consumed before the next window is read. A source lives for one query on one segment, so a query holds at most one context and one buffer per segment it reads, created only if it decodes a zstd window; before, each window created and released them. Compaction decodes through an allocation gate, which keeps the old path, as does a cursor given no decompressor. Hot phrase queries on data whose position windows are mostly zstd (10M rows, interleaved A/B in one process, on top of the plain-decode change): 0.95-0.96x for the two most position-heavy queries, the others within noise. ### Release note None ### Check List (For Author) - Test: Unit Test (SniiZstdDecompressor: frames of different sizes through one decompressor, corruption reported and the next frame decoded; PrxPodTest: random windows decoded through one shared decompressor) - Behavior changed: No - Does this need documentation: No Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
/review |
There was a problem hiding this comment.
Reviewed all 11 changed files and the related MATCH, SEARCH/TopK, phrase/prefix, scoring, frame-parser and compaction paths at head 9ca7f96. One new P2 finding: the source-owned decompression buffer retains untracked query memory. No existing inline findings were present. No additional user focus was supplied.
Critical checkpoint conclusions:
- Goal/proof: the implementation reduces per-document decoder calls and reuses zstd state for CSR windows. New unit tests compare raw/zstd selective and full output with input and check reuse/recovery; performance and runtime correctness were not executed or measured here.
- Scope/clarity: focused reader/codec optimization; no unrelated source changes. One retained-buffer accounting issue is reported inline.
- Concurrency/locks: actual collectors decode serially and create sources per query/binding; wave callbacks execute serially and attach encoded slices. No new lock or lock-order change; no reachable scratch race found.
- Lifecycle/static initialization: execution contexts retain sources while cursors run. Decoded positions live in cursor-owned vectors, so later decompression cannot invalidate returned spans. Lazy RAII cleanup has no new ownership cycle or static initialization dependency; retained allocation accounting is the exception identified inline.
- Configuration: no new or changed settings.
- Compatibility: disk framing, codec IDs and persisted bytes are unchanged. Default-null constructor arguments retain the old direct-cursor path; no external ABI/protocol change identified.
- Thrift/protobuf: no changes.
- Parallel paths: both full and selective CSR receive the helper. Raw/PFOR are unaffected; deferred streaming keeps its independent buffer; compaction allocation gates override shared decompression.
- Conditions/error handling: comments explain fast/checked fallback and reuse. Speculative appends roll back before the checked decoder restarts at the original cursor; caps, truncation, overflow, ordinal and trailing-byte checks remain. Non-OK statuses propagate through existing query exception boundaries.
- Coverage: deterministic reuse/grow/shrink/empty/corruption tests and randomized valid raw/zstd windows were inspected, alongside existing PFOR, shape, stats, CRC, overflow and allocation-gate tests. Limits: random per-document counts are only 0..5, not multi-byte count headers or UINT32_MAX overflow cases; no new targeted malformed-inner-varint selective, simultaneous gate+zstd, tracker-accounting or two-cursor interleaving test. Direct parser/ownership/dispatch inspection resolved these code questions; tests were not run.
- Expected results: new unit-test expected values derive from generated input/oracles; no regression output files changed.
- Observability: successful-frame decode statistics and error propagation are preserved. No extra hot-path logging was introduced; memory accounting requires the inline fix.
- Transactions/persistence: no EditLog, commit, failover or visibility logic changed; committed-data/version invariants are unaffected by the scope.
- Writes/atomicity: no write, delete-bitmap or rowset lifecycle mutation changed; no new crash-atomicity obligation.
- FE/BE propagation: no cross-process variables added.
- Performance/memory: repeated context allocation and output zero-fill are avoided; high-water retention is intentional, but its memory must be tracked. No benchmark claims are independently confirmed. The text-only BE build-hygiene checks passed (headers, budgets/PCH, extern-template pairs and unity-skip coverage).
- Other issues: no additional substantiated decoding, source-lifetime, format or integration regression remained after the missed-issue recheck.
Static review only: no builds, unit/regression tests, benchmarks, runtime measurements or final ELF/GLIBC validation were performed; no source files were modified. Review convergence is reported separately by the delivery helper.
Review converged after 2 round(s).
…cker The decompressor's output buffer lasts as long as its SniiIndexSource and is as large as the largest window decoded, but new[] is not tracked: the jemalloc hook only forwards, and consumption and limit checks happen in the Doris Allocator. Allocate it with DorisUniqueBufferPtr (Allocator<false>, no zero-fill), releasing the old buffer before the new one is allocated. Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
run buildall |
|
/review |
There was a problem hiding this comment.
Reviewed all 11 changed files at 6fd35b186f24222ba3a9dd77b86a79f4617a7663, including the query callers, CSR consumers, checked decoders and allocation paths. No new actionable findings. The existing P2 memory-tracking finding is fixed: the retained buffer uses DorisUniqueBufferPtr with paired Doris allocation/release, and growth frees the prior buffer first. No existing P0/P1 finding remains to carry forward. No additional user focus was provided.
Checkpoint conclusions:
- Goal and proof: the implementation removes ordinary per-document Status calls and reuses query-side zstd context/storage. Added unit tests inspectably cover output equivalence, reuse, corruption recovery and retained-buffer accounting; runtime correctness and speed were not measured here.
- Scope and reuse: changes are focused on the read hot path, preserve checked fallbacks and reuse the Doris allocator.
- Concurrency and locks: actual MATCH, SEARCH, nested and scored callers execute each source synchronously. Batched I/O callbacks do not decompress. Different scanner evaluations own different sources; no new thread, lock or lock-order change was found.
- Lifecycle and static initialization: sources outlive their cursors on the traced production paths; borrowed plaintext is consumed into cursor-owned CSR vectors before another decode. Sources release inside the task scope and before their opened indexes. Context/buffer ownership is balanced; no new static initialization dependency or cycle.
- Configuration: none added or changed.
- Compatibility: on-disk codecs, frame layouts, reader limits and writer behavior are unchanged. No new system/dependency requirement was identified; binaries were not built or audited.
- Thrift/protobuf: no generated definitions changed.
- Parallel paths: full, selective and dense-selection CSR propagate reuse; PFOR remains unchanged. Allocation-gated compaction retains its reservation path, and streaming retains its own plaintext because views survive between calls.
- Conditional checks: bounds, terminators, overflow and whole-run rollback preserve checked-decoder behavior. Comments explain the fast/fallback and buffer-growth branches.
- Tests: deterministic randomized RAW/ZSTD full/selective oracle and codec reuse/error/tracker tests supplement existing format/consumer tests. Tests were inspected, not executed. New randomized counts stay at most five and do not approach UINT32_MAX; targeted malformed selective payload and gate-plus-reuse cases would strengthen automated coverage. Those branches were examined statically with no unresolved defect.
- Test results: no regression output files changed; expected positions are derived from input rather than handwritten outputs.
- Observability: existing corruption/allocation statuses and successful-decode statistics remain available; errors do not commit partial decode statistics. No additional logging or metric need was established.
- Transactions and persistence: no transaction, visible-version, delete-bitmap, metadata replay or persistence change.
- Data writes and crash behavior: the change is read-only; retained resources use owned cleanup on success and error paths.
- FE/BE variable passing: none added or changed.
- Performance: hot loops avoid ordinary Status overhead and repeated zero-fill/context allocation; exceptional multi-byte runs replay through checked decoding. The largest plaintext buffer remains retained and tracked until source destruction. No benchmark claim was independently verified.
- Other BE checkpoints: no PCH, gate-table, explicit-instantiation, renamed-header or source-including-test changes. The pure-text
build-support/check-build-hygiene.shpassed.
Static review only: no builds, unit/regression tests, benchmarks or source modifications. Both normal reviewers and the independent risk reviewer returned NO_NEW_VALUABLE_FINDINGS; all assigned scope and risk dispositions are complete. Review converged in 1 round with no unresolved candidates.
Review converged after 1 round(s).
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
TPC-H: Total hot run time: 28738 ms |
TPC-DS: Total hot run time: 151223 ms |
ClickBench: Total hot run time: 24.36 s |
…prx windows (#69769) ### What problem does this PR solve? Issue Number: None Related PR: #69649, #69770 Problem Summary: #69649 stores a .prx window as PFOR instead of zstd when zstd saves less than `snii_prx_zstd_min_saving_percent` (30) of the PFOR frame, because every read of a zstd window pays a decompression. What that costs and buys depends on how much zstd saves on the data. Replaying the 1.6M windows of 10M AgentLogs rows, 30 spends 8% more bytes on the windows zstd compresses and cuts their decode time by 42%; on the windows of TextBench service logs it spends 5% and cuts 6%; on data whose windows zstd shrinks by just under 30% it stores every window as PFOR. No single percentage fits all data. Each index of a segment now spends a size budget instead: `PrxZstdBudget`, owned by its `LogicalIndexWriter` and reached through `PrxWindowLimits`, so the resident and the spilled encoder, and the ordinary and the compaction build, all use it. A window whose smallest frame is zstd is stored in its faster frame (PFOR, or raw when smaller) when - its saving is below the share whose trades, over the windows the index has seen, fit 8% of their smallest frames, which puts the budget on the windows zstd shrinks least, and - the bytes the index has actually traded, this window included, still fit 8% of the smallest frames seen. This makes 8% a bound for any order of windows: fed the TextBench windows from the largest saving to the smallest, the share alone spends 36%. Until it has seen 64 windows the share is 30, the previous default. The windows counted are those that get a zstd frame (a plain payload of at least 512 bytes), the only ones whose codec a share decides; singleton and short windows are written as before and counted neither in the allowance nor in the warmup. The choice uses the frames the writer builds anyway: nothing is compressed twice or scanned ahead, and the same input gives the same bytes. `snii_prx_zstd_min_saving_percent` now defaults to -1 (the budget); 0-100 keeps a fixed share, 0 the smallest frame. The budget is 8% rather than less: with it the AgentLogs phrase queries below read nearly the same frames as with 30, while in the replay a 5% budget cuts the decode time by 31% instead of 39%. Same binary, one stream load per table, size against the smallest frames (0): | data | index, 30 | index, budget | table, 30 | table, budget | |---|---|---|---|---| | AgentLogs 99M rows | +4.13% | +3.65% | +1.92% | +1.69% | | AgentLogs 10M rows | +4.59% | +3.37% | +2.13% | +1.57% | | TextBench 12M rows | +0.89% | +0.79% | +0.51% | +0.45% | - The phrase queries read the same frames with 30 and with the budget: at 99M rows all PFOR for DS1, DS6, DS7, A6 and A9 (for example 107,307 frames for DS7), and about 11,170 zstd frames of about 259,000 for A10 with both; on TextBench most windows stay zstd either way (582 against 583 zstd frames of 599 for 'connection reset'). - Hot queries in one process, budget data against 30 data with the same read path (paired cycles: 6 for the 25 AgentLogs queries at 10M rows, 10 for the 15 TextBench queries): 0.96-1.06 and 0.97-1.05; every query returns the same result. - Against the data written before #69649 (smallest frames), the 11 AgentLogs phrase queries at 99M rows take 0.83x in geometric mean with the budget data (DS7 0.63x, A6 0.67x, A9 0.70x, DS4 0.74x, A10 0.77x), as with 30 (0.83x). This run also had the read-path change of #69770, which does not touch the PFOR windows these queries read. - Data bytes are identical, and the index written with 0 and with 30 has exactly the size the previous binary writes. - Write cost: the choice adds about 48 ns per window, 79 ms over the 1.6M AgentLogs windows. ### Release note SNII now chooses per index how many position windows to store in the faster but larger PFOR form, spending at most 8% of the size of the windows zstd compresses; `snii_prx_zstd_min_saving_percent` defaults to -1 for this, and 0-100 still sets a fixed percentage.
### What problem does this PR solve? Issue Number: None Related PR: #69649, #69769 Problem Summary: A phrase query decodes the positions of the selected documents of every .prx window it reads. Timed per window on a 10M-row AgentLogs load, a zstd window cost 18.6 us against 1.4 us for a PFOR window: 11.7 us to decode the plain payload, 4.8 us to decompress, and about 2 us more because every window created and freed its own zstd context (about 96 KB) and a zero-filled output vector. Two commits: 1. **Decode the plain payload without a Status per document.** `decode_payload_csr_selective` made at least one out-of-line call returning a Status for every document of the window, selected or not (`get_varint32_fast`, `skip_varints`, `decode_delta_run`). The loop now keeps the cursor in a register and handles the usual cases inline: a single-byte count, walking past the deltas of a document that is not selected, and a run of single-byte deltas. Anything else -- a multi-byte value, a run that does not fit, a prefix sum that would overflow -- goes to the checked decoders from the same cursor, so they decide and report as before. The output vector grows as before; nothing is reserved up front. 2. **Reuse one zstd context and buffer per index source.** `ZstdDecompressor` keeps one context, created at the first zstd frame, and one output buffer that only grows and is not zero-filled (decompression writes every byte before it is read). The buffer comes from the Doris allocator (`DorisUniqueBufferPtr`), so the decoding task's memory tracker accounts for it while it is held. `SniiIndexSource` owns one, and the cursors it opens pass it to the .prx decoder through `PrxDecodeContext`. The cursors of a source decode on its thread one window at a time, and the decoded payload is consumed before the next window is read. A source lives for one query on one segment, so a query holds at most one context and one buffer per segment it reads, and only if it decodes a zstd window; before, each window created and released them. Compaction decodes through an allocation gate, which keeps the old path, as does a cursor given no decompressor. Hot queries, old against new read path in one process (run-time switch in an experiment build, 6 paired cycles), on 99M AgentLogs rows written with the smallest frames, as every segment written before #69649 is (mostly zstd windows): DS7 (unfiltered phrase) 0.87x, A6 0.89x, A10 0.93x, DS4 (phrase prefix) 0.94x, A9 0.95x, DS1 0.96x; repeating the old path against itself gave 0.93-1.05. The gain follows the zstd windows a query reads: the phrase queries of AgentLogs written with #69649 read PFOR windows and do not change, and on TextBench, whose large windows stay zstd, the time per window is the decompression itself and the change is within noise. Every query returns the same result. ### Release note None
…aster #69770 (#69788) Cherry-picked from #69770 Co-authored-by: Jack <[email protected]>
… on faster .prx windows #69769 (#69796) ### What problem does this PR solve? Issue Number: None Related PR: #69769, #69649 (backport #69795), #69770 (backport #69788) Problem Summary: Backport of #69769 to branch-4.2, stacked on #69795 (the backport of #69649). #69649 stores a .prx window as PFOR instead of zstd when zstd saves less than `snii_prx_zstd_min_saving_percent` (30) of the PFOR frame, because every read of a zstd window pays a decompression. What that costs and buys depends on how much zstd saves on the data. Replaying the 1.6M windows of 10M AgentLogs rows, 30 spends 8% more bytes on the windows zstd compresses and cuts their decode time by 42%; on the windows of TextBench service logs it spends 5% and cuts 6%; on data whose windows zstd shrinks by just under 30% it stores every window as PFOR. No single percentage fits all data. Each index of a segment now spends a size budget instead: `PrxZstdBudget`, owned by its `LogicalIndexWriter` and reached through `PrxWindowLimits`, so the resident and the spilled encoder, and the ordinary and the compaction build, all use it. A window whose smallest frame is zstd is stored in its faster frame (PFOR, or raw when smaller) when - its saving is below the share whose trades, over the windows the index has seen, fit 8% of their smallest frames, which puts the budget on the windows zstd shrinks least, and - the bytes the index has actually traded, this window included, still fit 8% of the smallest frames seen. This makes 8% a bound for any order of windows: fed the TextBench windows from the largest saving to the smallest, the share alone spends 36%. Until it has seen 64 windows the share is 30, the previous default. The windows counted are those that get a zstd frame (a plain payload of at least 512 bytes), the only ones whose codec a share decides; singleton and short windows are written as before and counted neither in the allowance nor in the warmup. The choice uses the frames the writer builds anyway: nothing is compressed twice or scanned ahead, and the same input gives the same bytes. `snii_prx_zstd_min_saving_percent` now defaults to -1 (the budget); 0-100 keeps a fixed share, 0 the smallest frame. The budget is 8% rather than less: with it the AgentLogs phrase queries below read nearly the same frames as with 30, while in the replay a 5% budget cuts the decode time by 31% instead of 39%. Same binary, one stream load per table, size against the smallest frames (0): | data | index, 30 | index, budget | table, 30 | table, budget | |---|---|---|---|---| | AgentLogs 99M rows | +4.13% | +3.65% | +1.92% | +1.69% | | AgentLogs 10M rows | +4.59% | +3.37% | +2.13% | +1.57% | | TextBench 12M rows | +0.89% | +0.79% | +0.51% | +0.45% | - The phrase queries read the same frames with 30 and with the budget: at 99M rows all PFOR for DS1, DS6, DS7, A6 and A9 (for example 107,307 frames for DS7), and about 11,170 zstd frames of about 259,000 for A10 with both; on TextBench most windows stay zstd either way (582 against 583 zstd frames of 599 for 'connection reset'). - Hot queries in one process, budget data against 30 data with the same read path (paired cycles: 6 for the 25 AgentLogs queries at 10M rows, 10 for the 15 TextBench queries): 0.96-1.06 and 0.97-1.05; every query returns the same result. - Against the data written before #69649 (smallest frames), the 11 AgentLogs phrase queries at 99M rows take 0.83x in geometric mean with the budget data (DS7 0.63x, A6 0.67x, A9 0.70x, DS4 0.74x, A10 0.77x), as with 30 (0.83x). This run also had the read-path change of #69770, which does not touch the PFOR windows these queries read. - Data bytes are identical, and the index written with 0 and with 30 has exactly the size the previous binary writes. - Write cost: the choice adds about 48 ns per window, 79 ms over the 1.6M AgentLogs windows. ### Branch adaptations None. `git cherry-pick 0571eb6` applied cleanly on top of the backport of #69649, which it needs: it changes the setting #69649 adds, and the automatic pick to branch-4.2 failed because branch-4.2 does not have #69649. This PR is stacked on that backport, #69795, so it shows both commits until #69795 merges; merge #69795 first. ### Validation - Built and run with both backports (this one and the stacked #69769 backport) applied to branch-4.2 at 711db43, the commit before #69625: its lance-c update is not in the local third-party build, and the 16 commits after it touch no SNII file. `PrxPod*`, `Snii*`, `DorisSniiFileReader*`, `*InvertedIndex*`, `*IndexFileWriter*` and `*IndexFileReader*`: 1710 tests passed, including the new budget, codec choice, writer and configuration tests. - On master both changes passed CI. - Not built locally on the branch-4.2 tip; this PR's BE UT run covers that. ### Release note SNII now chooses per index how many position windows to store in the faster but larger PFOR form, spending at most 8% of the size of the windows zstd compresses; `snii_prx_zstd_min_saving_percent` defaults to -1 for this, and 0-100 still sets a fixed percentage. ### Check List (For Author) - Test: Unit Test - SniiPrxZstdBudget: the prior share, the windows zstd shrinks least are traded first, the bound under a descending order, windows with nothing to trade. - SniiPrxPodTest: the faster frame (PFOR or raw) and when the budget is asked. - SniiStreamedWriterSessionTest: windows that save 1-29% through the ordinary and the streamed (compaction) build; 30 trades all of them, the budget at most 8% of the smallest frames. - SniiWriterPrxZstdSaving: the default and the config mapping. - Manual test: index size of 10M and 99M AgentLogs and 12M TextBench loads with 0, 30 and the budget; frames read per codec from query profiles; interleaved hot A/B in one process. - Behavior changed: Yes (the default .prx codec choice of newly written segments; existing segments are read as before) - Does this need documentation: No 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: martin.foo838 <[email protected]> Co-authored-by: Claude Opus 5.5 <[email protected]>
What problem does this PR solve?
Issue Number: None
Related PR: #69649, #69769
Problem Summary: A phrase query decodes the positions of the selected documents of every .prx window it reads. Timed per window on a 10M-row AgentLogs load, a zstd window cost 18.6 us against 1.4 us for a PFOR window: 11.7 us to decode the plain payload, 4.8 us to decompress, and about 2 us more because every window created and freed its own zstd context (about 96 KB) and a zero-filled output vector. Two commits:
decode_payload_csr_selectivemade at least one out-of-line call returning a Status for every document of the window, selected or not (get_varint32_fast,skip_varints,decode_delta_run). The loop now keeps the cursor in a register and handles the usual cases inline: a single-byte count, walking past the deltas of a document that is not selected, and a run of single-byte deltas. Anything else -- a multi-byte value, a run that does not fit, a prefix sum that would overflow -- goes to the checked decoders from the same cursor, so they decide and report as before. The output vector grows as before; nothing is reserved up front.ZstdDecompressorkeeps one context, created at the first zstd frame, and one output buffer that only grows and is not zero-filled (decompression writes every byte before it is read). The buffer comes from the Doris allocator (DorisUniqueBufferPtr), so the decoding task's memory tracker accounts for it while it is held.SniiIndexSourceowns one, and the cursors it opens pass it to the .prx decoder throughPrxDecodeContext. The cursors of a source decode on its thread one window at a time, and the decoded payload is consumed before the next window is read. A source lives for one query on one segment, so a query holds at most one context and one buffer per segment it reads, and only if it decodes a zstd window; before, each window created and released them. Compaction decodes through an allocation gate, which keeps the old path, as does a cursor given no decompressor.Hot queries, old against new read path in one process (run-time switch in an experiment build, 6 paired cycles), on 99M AgentLogs rows written with the smallest frames, as every segment written before #69649 is (mostly zstd windows): DS7 (unfiltered phrase) 0.87x, A6 0.89x, A10 0.93x, DS4 (phrase prefix) 0.94x, A9 0.95x, DS1 0.96x; repeating the old path against itself gave 0.93-1.05. The gain follows the zstd windows a query reads: the phrase queries of AgentLogs written with #69649 read PFOR windows and do not change, and on TextBench, whose large windows stay zstd, the time per window is the decompression itself and the change is within noise. Every query returns the same result.
Release note
None
Check List (For Author)
🤖 Generated with Claude Code