DataPage smart write through #367
Closed
Conversation
This file contains 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
Scooletz
added
🐌 performance
Minimum allowed line rate is |
Merged
|
Introduced and handled in #375 |
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.
This PR introduces a change in the way of handling overflown
DataPages.In current situation, when a page is full and there's no place to put the new key in it, it will be flushed down. The flushing down is a powerful mechanism but requires to iterate over the
SlottedArray, move items down and delete them in the original page. If theDataPageis near the top, this situation may happen quite frequently.This PR introduces an additional check using
batch.WasWrittenthat allows to check if a child page was written during this batch. If a key does not fit to a page (SlottedArray.TrySetfailed), is non-empty (can have a nibble truncated), a child page exist andWasWrittenduring this batch, it's a perfect opportunity to pass through this page and move down.The expectation is that by limiting the amount of time spent in flushing down, we could greatly decrease the time of applying a block. This would help with a lot of cases where there's a bulk of updates for a given account but we don't want to flush a few layers of
DataPages constantly. The disadvantage is that this limits LRU behavior a bit (values pushed down in the tree).To be implemented and tested.