Two-rowID-leaf support in the conflict manager and general refactoring #18194
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
|
Looks good from my side - @Tishj can you do a pass? |
github-actions bot
pushed a commit
to duckdb/duckdb-r
that referenced
this pull request
Jul 24, 2025
Two-rowID-leaf support in the conflict manager and general refactoring (duckdb/duckdb#18194)
github-actions bot
added a commit
to duckdb/duckdb-r
that referenced
this pull request
Jul 24, 2025
Two-rowID-leaf support in the conflict manager and general refactoring (duckdb/duckdb#18194) Co-authored-by: krlmlr <krlmlr@users.noreply.github.com>
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.
Overview
#15092 made it possible for ART
PRIMARY/UNIQUEindexes to have at most two row IDs per (unique) leaf.Currently, the conflict manager (and
ART::VerifyLeaf) still work with the assumption that there can never be more than one row ID per conflict hit. Since this assumption no longer holds, in some cases, we now have to register conflict hits for up to two row IDs. Related issue: https://github.com/duckdblabs/duckdb-internal/issues/4924. Later in the execution, we need to understand which of the two possible row IDs is visible to the transaction (and the conflict manager).As far as I can tell, this mostly kept working because we use a
vectorfor row ID scanning, which is order-preserving, and newer row IDs (more likely the ones visible to the current transaction) overwrote older row IDs.Changes in this PR
CanFetchtoDataTable,LocalStorage,RowGroupCollectionto determine whether a row ID is visible to a transaction/in the local storage, or not.Also, I've refactored basically the entire conflict manager. That refactoring includes removing the
ManagedSelection, and a lot of code paths. I think the number of lines only went up because I've added theCanFetchstuff and because I've also added a lot of comments and some formatting). 😅This PR is a minor follow-up to #18015 and next up is turning the row ids into an unordered set instead of a vector.