Michael Kleen
Michael Kleen
A common optimization for this problem is [Eager Aggregation and Lazy Aggregation](https://www.vldb.org/conf/1995/P345.PDF) which is probably worth having a deeper look at.
@mfussenegger I made a second iteration to handle outer joins properly. Outer-joins only apply constant join conditions on their non-preserved side and get ignored on the other side: - Left-joins...
The test is still flaky, i will put this on hold.
This use case will greatly benefit from the implementation https://github.com/crate/crate/issues/13337#issuecomment-2176149571
> Hi! Is this issue still open ? If it is, I would like to work on this. Thanks Hello, yes, this issue is still open, but it's not estimated...
Yes i agree. The write up tries to explain the difference between a fully cost-based approach like cockroachdb or hive against a hybrid-approach like presto or duckdb. I was more...
@hlcianfagna Thanks for the great input!
From my perspective, the following parts are missing: - Make Logical Plans identifiable, add ids to logical plans. The algorithm uses binary set operations to find the solution, each operator...
This is a general workflow how I would structure it: ```mermaid flowchart TD A[Sql] -->B(Analyzed Statement) B -->C(Planner) C -->D(Logical Plan Tree) D -->E(Enter Optimizer) E -->F(Push down Filters/Projections for...
> It's currently not completely clear what is missing in our planner to support any join order algorithm, like do our existing join operators (join pairs) have enough information declared,...