Refactor table read state #3392
Merged
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
andyfengHKU
force-pushed
the
refactor-table-read-state
branch
2 times, most recently
from
f7d3ca1
to
7c92677
Compare
ray6080
force-pushed
the
refactor-table-read-state
branch
from
bdd5ceb
to
4dddb48
Compare
ray6080
approved these changes
Apr 29, 2024
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 refactors interfaces for
ScanTableand its children classes. In particular, it contains changes onvector<ValueVector>inScanTablesince we already store the same information inTableReadState. I still have to keep a vector for input and output respectively in order to retrieve their state. I don't think we will be able to solve this because in multi-table scan there are cases where we don't scan a physical table at all. So relying only onTableReadStateto set the correct scan result doesn't sound safe to menodeIDVectorfrom parameter list ofinitializeReadStatebecause we seem to have the guarantee that it's always the same vector asnodeIDVectorinreadStateI spot another case inNodeTable::initializeReadStatewhere we seem to re-createNodeDataReadStateunnecessarily. @ray6080 should take a look at this.