Github user nongli commented on the pull request:
https://github.com/apache/spark/pull/9480#issuecomment-154518082
> In general, I think we'd better add more IR (Intermediate Representation,
should be the Expression or Logical Plan node here) for common sub expression
cases, and we then we can identify the common sub expressions and transform to
the new IRs, which should be more clean for code gen part of work.
>As the codegen code is a runtime behavior, which is difficult to debug and
maintain, more IR will be helpful for this case, and that's also how a modern
compiler works.
>And I don't think the approach I described can be done right now, it's
will be a big change, actually, we have lots of similar optimization like
"Common Table Expression" (CTE), or self join can be optimized in the same way,
it will be cool if we can figure a approach for the general common xxx
elimination.
I'm still not sure how you are suggesting we execute the version you are
proposing. I'd guess you do that by adding an additional project that creates a
new intermediate row and substitute the common subexpression to read from that
new intermediate row. I think this is bad for performance. One of the big
benefits of codegen is to remove those "unnecessary" intermediate rows.
I agree that we should expand this logic in planning and analysis but I
think the utility class to compute equivalence is reusable in other parts.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
