Unify index key representation in query plan#5275
Open
joshua-spacetime wants to merge 3 commits into
Open
Conversation
a12fef7 to
736ae71
Compare
736ae71 to
fa08c01
Compare
a765440 to
28a0f79
Compare
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
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.
Description of Changes
Refactors index probes so that multi-column index keys are represented as a single product value expression
PhysicalExpr::Productinstead of being split across various fields and structs. As a result, this patch also simplifies the index-scan and index-join query executor variants now that index scans/probes share one physical shape.This change is in preparation for adding formal parameters to query plans. Since index probe values now have single unified representation as a
PhysicalExpr, a future parameterized plan can represent an index scan or index join as follows:This will avoid having to duplicate parameter handling in a bunch of different places or rules.
Note, a very nice consequence of this refactor is that it removes/consolidates a significant amount of code as the diff shows.
API and ABI breaking changes
N/A
Expected complexity level and risk
...
Testing
Existing coverage