misc: reuse owned parquet string dictionary page buffers - #808
Open
lizhen-0710 wants to merge 1 commit into
Open
misc: reuse owned parquet string dictionary page buffers#808lizhen-0710 wants to merge 1 commit into
lizhen-0710 wants to merge 1 commit into
Conversation
|
|
Avoid keeping two resident copies of large string dictionary pages after decoding. For BYTE_ARRAY dictionary pages, the decoded string data can already live in PageReader-owned storage: the decompressed page buffer for compressed pages or the decrypted buffer for encrypted uncompressed pages. When the current page data points at one of those owned buffers, move that buffer directly into dictionary_.strings instead of allocating a second buffer and copying the bytes. Also clear dictionary-page scratch buffers after dictionary materialization so non-adopted page storage does not linger on the PageReader. Add targeted tests for decompressed and decrypted buffer adoption, plus an end-to-end compressed string dictionary read under a constrained memory pool to catch regressions back to the duplicate-copy behavior. Verified with: CCACHE_DISABLE=1 _build/Release/bolt/dwio/parquet/tests/reader/bolt_dwio_parquet_reader_test --gtest_filter='ParquetReaderTest.stringDictionaryTakesOwnedPageBuffers:ParquetReaderTest.compressedStringDictionaryDoesNotKeepDuplicatePageCopy' Verified with: CCACHE_DISABLE=1 ctest --test-dir _build/Release -R 'parquet|Parquet' --output-on-failure Co-authored-by: TRAE CLI <noreply@bytedance.com>
lizhen-0710
force-pushed
the
misc-parquet-dictionary-buffer-ownership
branch
from
July 30, 2026 11:13
4f9eb08 to
30426e2
Compare
guhaiyan0221
approved these changes
Jul 30, 2026
guhaiyan0221
left a comment
guhaiyan0221
left a comment
Collaborator
There was a problem hiding this comment.
Thank you for this improvement.
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
3 participants
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.
What problem does this PR solve?
Avoid keeping two resident copies of large string dictionary pages after decoding. For BYTE_ARRAY dictionary pages, the decoded string data can already live in PageReader-owned storage: the decompressed page buffer for compressed pages or the decrypted buffer for encrypted uncompressed pages.
Type of Change
Description
When the current page data points at one of those owned buffers, move that buffer directly into dictionary_.strings instead of allocating a second buffer and copying the bytes. Also clear dictionary-page scratch buffers after dictionary materialization so non-adopted page storage does not linger on the PageReader.
Add targeted tests for decompressed and decrypted buffer adoption, plus an end-to-end compressed string dictionary read under a constrained memory pool to catch regressions back to the duplicate-copy behavior.
Performance Impact
No Impact: This change does not affect the critical path (e.g., build system, doc, error handling).
Positive Impact: I have run benchmarks.
Click to view Benchmark Results
Negative Impact: Explained below (e.g., trade-off for correctness).
Release Note
Please describe the changes in this PR
Release Note:
Checklist (For Author)
Breaking Changes
No
Yes (Description: ...)
Click to view Breaking Changes