-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatbuffer definitions for index queries #821
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just formatting nits.
@@ -29,9 +29,19 @@ table table_scan_info_t { | |||
type_id: uint64; | |||
} | |||
|
|||
enum index_query_type_t:uint8 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
space after :
} | ||
|
||
table index_range_query_t { | ||
query_type : index_query_type_t; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use existing convention foo: bar
(this shows we need a precommit hook to autoformat .fbs
files, because I hate bringing up these nits).
table index_scan_info_t { | ||
index_id: uint64; | ||
txn_id : uint64; | ||
queries : [index_range_query_t]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need multiple queries per index scan?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To specify upper bound and lower bound mostly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Come to think of it I can do a real union type for that one.
Long-term question: for range queries, do we want to store sortkeys in the index rather than raw key values? If we can use binary comparison rather than locality-sensitive collation, that could potentially be a huge perf win. |
For preview we are only supporting POINT_READs,
Eventually support for UPPER, LOWER, EQUALS range query will be supported.