Type Model

[connortsui20]

This PR models almost all of the types that will be necessary for optimization. This includes:

• generic relational algebra operators that allow us to use the same "type" for both expressions in the memo table and operators in the plans
• logical / physical plans
• scalar operators and expressions
• partially materialized logical plans for rule binding
• transformation rule + implementation rule trait and some empty structs that implement them

I've named the crate itself optd-core. This can be subject to change, but I feel this is a reasonable default for now.

TODO: need to wait on #3 and #12 to be merged before proper CI checks can happen

Edit: I removed the cargo rustdoc check because its creating more problem than it would solve, see #14

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[AlSchlo]

Renamed some variables for clarity, and moved around some code.

I added support to expressions and scalars.
Also added some MVP operators in there.

[connortsui20]

@AlSchlo Several thoughts:

• Are we using the same GroupId for both relational and scalar groups? I actually don't have a strong preference either way, since that is easily changed in the future
• I don't really like the name RelLink because I still think that Rel is somewhat ambiguous (hence why I spelled out "relational" every time I used it). I also abandoned Link because I felt it was not descriptive enough
• Calling the root operator node instead of root I think is somewhat questionable, but I don't have any strong feelings about it
• I'm not totally convinced about the LogicalExpression and PhysicalExpression enums, as it implies that scalars can be both a logical expression and a physical expression. Based on what we talked about yesterday, this doesn't really make a lot of sense -- scalars should be a completely different type. So I'm inclined to keep a RelationalExpression and ScalarExpression type...

[AlSchlo]

Are we using the same GroupId for both relational and scalar groups?

Yes. We already have the differentiator in the "upper" layer of the enum, right?

I don't really like the name RelLink because I still think that Rel is ambiguous

Me neither, but I liked child even less, as scalars are also children.

Calling the root operator node instead of root

Yes, since it's not always the root. I find that to be confusing.

I'm not totally convinced about the LogicalExpression and PhysicalExpression enums

Requires some extra thought. Not too sure if we want Scalars as a completely different type. They are after all both logical and physical in Cascades.

[yliang412]

Great work guys. This is solid foundation. Besides the nits, the two main improvements I want to point out us regarding the transformation rule API and ways we represent subqueries in the system.

For the transformation rule API, to add newly generated expressions back to the memo table + recursively check for duplicates, you probably want to return some kind of partial plan.

For subqueries, I would argue we might want to handle it in some form of our representation. So there is the case where scalar could contain relation children. But after normalization, we should be fine. We might also want to support executing a subquery without unnesting (it will be a useful feature).