-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: clarify the meaning of plans #616
feat: clarify the meaning of plans #616
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very helpful -- thank you, @westonpace!
I think the new text makes a good job in distinguishing root and non-root relations and what their purposes are. The only comment I have is that the current terminology is not in line with the field names in the protobuf definitions: there we have one "plan" (i.e., one Plan
message) that contains several (root or non-root) "relations" (i.e., several PlanRel
messages), whereas here we have several "plans" that contain "a tree of relations" (which could be read as "one tree of relations").
How about aligning the terminology with the one from protobuf? Something like "Substrait is designed to allow users to express [...] transformations. [...] Transformations are expressed in a 'plan' that consists of several 'relations'. Each relation is a tree of 'relational operators'. We distinguish between 'root relations', which are interpreted as the possible result(s) of the plan depending on the context, and 'non-root relations', which represent intermediate results that other relations can refer to but which by themselves are not part of the semantics of the plan. (In particular, they can be removed, if unused.)"
If you agree, I can make the changes, which look quite mechanic, but feel free to do them yourself if you don't want to wait for the round-trip.
This looks really good. Seems like a few small edits proposed that look good and then we should be able to merge. Ping @westonpace to push over the finishline. |
Co-authored-by: Ingo Müller <github.com@ingomueller.net>
Addressed comments. @jacques-n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good set of clarifications. Going to merge.
#612 and #613 highlighted a number of ambiguities in plan interpretation. I have made an attempt to clarify these based on my interpretation.