Update sequence number assignment method in WBWIMemTable
#13400
Closed
Conversation
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
|
@cbi42 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
pdillinger
approved these changes
Feb 19, 2025
| uint32_t column_family; // column family of the entry. | ||
| // The following three fields are only maintained when the WBWI is created | ||
| // with overwrite_key = true. | ||
| uint32_t update_count; // number of updates for this key up to this entry. |
There was a problem hiding this comment.
Let's mention explicitly somewhere that this is a 1-based count, not 0-based
| // | ||
| // WBWI with overwrite mode keeps track of the most recent update for each key, | ||
| // so this memtable contains one update per key usually. However, there is a | ||
| // special case where this memtable needs to emit an extra SingleDelete even |
There was a problem hiding this comment.
I assume discussion of special case for merge comes later?
There was a problem hiding this comment.
Yes, it will come later. It should be a small change where for merge we don't track only the most recent update.
c54ef30 to
45e9204
Compare
|
@cbi42 has updated the pull request. You must reimport the pull request before landing. |
cbi42
commented
Feb 19, 2025
| // | ||
| // WBWI with overwrite mode keeps track of the most recent update for each key, | ||
| // so this memtable contains one update per key usually. However, there is a | ||
| // special case where this memtable needs to emit an extra SingleDelete even |
There was a problem hiding this comment.
Yes, it will come later. It should be a small change where for merge we don't track only the most recent update.
| uint32_t column_family; // column family of the entry. | ||
| // The following three fields are only maintained when the WBWI is created | ||
| // with overwrite_key = true. | ||
| uint32_t update_count; // number of updates for this key up to this entry. |
|
@cbi42 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
facebook-github-bot
pushed a commit
that referenced
this pull request
Feb 21, 2025
Summary: added merge support for WBWIMemTable. Most of the preparation work is done in #13387 and #13400. The main code change to support merge is in wbwi_memtable.cc to support reading the Merge value type. The rest of the changes are mostly comment change and tests. Pull Request resolved: #13410 Test Plan: - new unit test - ran `python3 ./tools/db_crashtest.py --txn blackbox --txn_write_policy=0 --commit_bypass_memtable_one_in=100 --test_batches_snapshots=0 --use_merge=1` for several runs. Reviewed By: jowlyzhang Differential Revision: D69885868 Pulled By: cbi42 fbshipit-source-id: b127d95a3027dc35910f6e5d65f3409ba27e2b6b
ybtsdst
pushed a commit
to ybtsdst/rocksdb
that referenced
this pull request
Apr 27, 2025
…13400) Summary: This is a preparation for supporting merge in `WBWIMemTable`. This PR updates the sequence number assignment method so that it allows efficient and simple assignment when there are multiple entries with the same user key. This can happen when the WBWI contains Merge operations. This assignment relies on tracking the number of updates issued for each key in each WBWI entry (`WriteBatchIndexEntry::update_count`). Some refactoring is done in WBWI to remove `last_entry_offset` as part of the WBWI state which I find it harder to use correctly. Pull Request resolved: facebook#13400 Test Plan: updated unit tests to check that update count is tracked correctly and WBWIMemTable is assigning sequence number as expected. Reviewed By: pdillinger Differential Revision: D69666462 Pulled By: cbi42 fbshipit-source-id: 9b18291825017a67c4da3318e8a556aa2971326b
ybtsdst
pushed a commit
to ybtsdst/rocksdb
that referenced
this pull request
Apr 27, 2025
Summary: added merge support for WBWIMemTable. Most of the preparation work is done in facebook#13387 and facebook#13400. The main code change to support merge is in wbwi_memtable.cc to support reading the Merge value type. The rest of the changes are mostly comment change and tests. Pull Request resolved: facebook#13410 Test Plan: - new unit test - ran `python3 ./tools/db_crashtest.py --txn blackbox --txn_write_policy=0 --commit_bypass_memtable_one_in=100 --test_batches_snapshots=0 --use_merge=1` for several runs. Reviewed By: jowlyzhang Differential Revision: D69885868 Pulled By: cbi42 fbshipit-source-id: b127d95a3027dc35910f6e5d65f3409ba27e2b6b
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.
Summary: This is a preparation for supporting merge in
WBWIMemTable. This PR updates the sequence number assignment method so that it allows efficient and simple assignment when there are multiple entries with the same user key. This can happen when the WBWI contains Merge operations. This assignment relies on tracking the number of updates issued for each key in each WBWI entry (WriteBatchIndexEntry::update_count). Some refactoring is done in WBWI to removelast_entry_offsetas part of the WBWI state which I find it harder to use correctly.Test plan: updated unit tests to check that update count is tracked correctly and WBWIMemTable is assigning sequence number as expected.