feat: basic table scan planning #112
Conversation
| namespace iceberg { | ||
|
|
||
| /// \brief Builder class for creating TableScan instances. | ||
| class ICEBERG_EXPORT TableScanBuilder { |
There was a problem hiding this comment.
Do we need an abstraction for common parts of other scan builders? We may need more scan types for incremental, append-only, changelog, etc. If there's not much to abstract, I'm fine to keep it as is for now and refactor them later.
There was a problem hiding this comment.
Yes, in the Java implementation, the hierarchy of Scan and ScanTask has been defined. I will review this part and try to make it more abstract.
| }; | ||
|
|
||
| /// \brief Represents a task to scan a portion of a data file. | ||
| struct ICEBERG_EXPORT FileScanTask { |
There was a problem hiding this comment.
Before defining FileScanTask, should we abstract it a little bit? I haven't looked at other implementations yet. From the java impl, there's a hierarchy of ScanTask and FileScanTask is a combination of ContentScanTask and PartitionScanTask.
I'm not sure if we want to take the complexity to support the java SplittableScanTask, MergableScanTask, and ScanTaskGroup. We can revisit these later.
Co-authored-by: Gang Wu <[email protected]>
Co-authored-by: Gang Wu <[email protected]>
Introducing basic scan table data interface