Closed kevinzwang closed 2 weeks ago
Comparing kevin/swap-plan-scan-dependency
(0429eea) with main
(16f5a8c)
❌ 1
regressions
✅ 16
untouched benchmarks
:warning: Please fix the performance issues or acknowledge them on CodSpeed.
Benchmark | main |
kevin/swap-plan-scan-dependency |
Change | |
---|---|---|---|---|
❌ | test_show[100 Small Files] |
23.7 ms | 49.3 ms | -51.94% |
Attention: Patch coverage is 52.88303%
with 286 lines
in your changes missing coverage. Please review.
Project coverage is 77.62%. Comparing base (
f290f40
) to head (0429eea
). Report is 2 commits behind head on main.
@kevinzwang I took another look at this PR, and maybe it can be done in a separate PR, but we also need to invert the dependency between daft-table
and daft-logical-plan
.
@kevinzwang I took another look at this PR, and maybe it can be done in a separate PR, but we also need to invert the dependency between
daft-table
anddaft-logical-plan
.
I'll take a look at it, if it's a complex task i'll merge this one in first
This PR creates a better abstraction over scan tasks and uses that abstraction in the planning crates (daft-logical-plan, daft-physical-plan, daft-local-plan). This is done by creating a new
common-scan-info
crate which holds aScanTaskLike
trait which planning crates can use to access scan task info without needing knowledge of implementation.Now, in our planning stages, we solely use our ScanTaskLike abstraction, and then in execution, we downcast to ScanTask to actually materialize them. That way, we can actually remove the daft-scan dependency from planning crates.