Avoid copying into OwnedBytes when opening a fast field column Dictionary. - #55
Merged
Merged
Conversation
stuhood
force-pushed
the
stuhood.avoid-owned-bytes-dictionary
branch
from
July 13, 2025 23:16
73d0776 to
019de0d
Compare
eeeebbbbrrrr
approved these changes
Jul 14, 2025
eeeebbbbrrrr
left a comment
eeeebbbbrrrr
left a comment
There was a problem hiding this comment.
Nice.
This is a much smaller changeset than I had to do for the numeric fast fields!
stuhood
added a commit
to paradedb/paradedb
that referenced
this pull request
Jul 14, 2025
## What Lazily load fast field dictionaries from buffers: see paradedb/tantivy#55 ## Why A customer reported slower-than-expected paging on a string/uuid column. 85% of the time for that query was being spent in _opening_ a fast fields string/bytes column, with a large fraction of that time spent fully consuming the column's `Dictionary`. ## Tests See the attached benchmark results: * [`docs` dataset](#2842 (review)) * No regressions. * 2x faster for `top_n-score` * 1.4x faster for `highlighting` * [`logs` dataset](#2842 (review)) * No regressions. * 4.5x faster for `paging-string-max` * 1.7x faster for `paging-string-median` * 1.6x faster for `paging-string-min` The `paging-string-*` benchmarks were added in #2834 to highlight this particular issue.
stuhood
added a commit
to paradedb/paradedb
that referenced
this pull request
Jul 14, 2025
Lazily load fast field dictionaries from buffers: see paradedb/tantivy#55 A customer reported slower-than-expected paging on a string/uuid column. 85% of the time for that query was being spent in _opening_ a fast fields string/bytes column, with a large fraction of that time spent fully consuming the column's `Dictionary`. See the attached benchmark results: * [`docs` dataset](#2842 (review)) * No regressions. * 2x faster for `top_n-score` * 1.4x faster for `highlighting` * [`logs` dataset](#2842 (review)) * No regressions. * 4.5x faster for `paging-string-max` * 1.7x faster for `paging-string-median` * 1.6x faster for `paging-string-min` The `paging-string-*` benchmarks were added in #2834 to highlight this particular issue.
stuhood
added a commit
to paradedb/paradedb
that referenced
this pull request
Jul 14, 2025
Lazily load fast field dictionaries from buffers: see paradedb/tantivy#55 A customer reported slower-than-expected paging on a string/uuid column. 85% of the time for that query was being spent in _opening_ a fast fields string/bytes column, with a large fraction of that time spent fully consuming the column's `Dictionary`. See the attached benchmark results: * [`docs` dataset](#2842 (review)) * No regressions. * 2x faster for `top_n-score` * 1.4x faster for `highlighting` * [`logs` dataset](#2842 (review)) * No regressions. * 4.5x faster for `paging-string-max` * 1.7x faster for `paging-string-median` * 1.6x faster for `paging-string-min` The `paging-string-*` benchmarks were added in #2834 to highlight this particular issue.
stuhood
added a commit
to paradedb/paradedb
that referenced
this pull request
Jul 14, 2025
…2846) ## What Lazily load fast field dictionaries from buffers: see paradedb/tantivy#55 ## Why A customer reported slower-than-expected paging on a string/uuid column. 85% of the time for that query was being spent in _opening_ a fast fields string/bytes column, with a large fraction of that time spent fully consuming the column's `Dictionary`. ## Tests See the attached benchmark results: * [`docs` dataset](#2842 (review)) * No regressions. * 2x faster for `top_n-score` * 1.4x faster for `highlighting` * [`logs` dataset](#2842 (review)) * No regressions. * 4.5x faster for `paging-string-max` * 1.7x faster for `paging-string-median` * 1.6x faster for `paging-string-min` The `paging-string-*` benchmarks were added in #2834 to highlight this particular issue.
mdashti
pushed a commit
that referenced
this pull request
Oct 21, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
mdashti
pushed a commit
that referenced
this pull request
Oct 22, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
mdashti
pushed a commit
that referenced
this pull request
Oct 22, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
mdashti
pushed a commit
that referenced
this pull request
Dec 3, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
mdashti
pushed a commit
that referenced
this pull request
Dec 3, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Dec 3, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Dec 10, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Dec 10, 2025
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Jan 13, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Jan 13, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Jan 13, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
stuhood
added a commit
that referenced
this pull request
Jan 14, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
rebasedming
pushed a commit
that referenced
this pull request
Feb 10, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
rebasedming
pushed a commit
that referenced
this pull request
Feb 10, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers.
rebasedming
pushed a commit
that referenced
this pull request
Jun 22, 2026
…tionary`. (#55) When a fast fields string/bytes `Dictionary` is opened, we currently read the entire dictionary from `FileSlice` -> `OwnedBytes`... and then immediately wrap it back into a `FileSlice`. Switching to `Dictionary::open` preserves the `FileSlice`, such that only the portions of the `Dictionary` which are actually accessed are read from disk/buffers. (cherry picked from commit d15966f)
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
2 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.
When a fast fields string/bytes
Dictionaryis opened, we currently read the entire dictionary fromFileSlice->OwnedBytes... and then immediately wrap it back into aFileSlice.Switching to
Dictionary::openpreserves theFileSlice, such that only the portions of theDictionarywhich are actually accessed are read from disk/buffers.