Currently query execution logic is tightly coupled with storage layout without a clean separation in between.
It would make more sense to refactor it so that on an incoming query, the query is first parsed into an AST, then converted into a logic plan via a logical planner, then translated/optimized to a physical plan via a physical planner, then executed to derive results.
Segment fields will be represented as streams of data blocks, and executing query is a simple matter of continuously retrieving the next block from the streams. This would also allow partial results to be returned to the client side as soon as they become available, as opposed to waiting for the entire query to finish.
Additionally, query execution logic and optimizations will be encapsulated within the physical query operators as opposed to embedded in database segments, which provides better separation of concerns.
Currently query execution logic is tightly coupled with storage layout without a clean separation in between.
It would make more sense to refactor it so that on an incoming query, the query is first parsed into an AST, then converted into a logic plan via a logical planner, then translated/optimized to a physical plan via a physical planner, then executed to derive results.
Segment fields will be represented as streams of data blocks, and executing query is a simple matter of continuously retrieving the next block from the streams. This would also allow partial results to be returned to the client side as soon as they become available, as opposed to waiting for the entire query to finish.
Additionally, query execution logic and optimizations will be encapsulated within the physical query operators as opposed to embedded in database segments, which provides better separation of concerns.