Github user rednaxelafx commented on the issue:
https://github.com/apache/spark/pull/20224
Thanks for your comments, @viirya !
I'd say only having (1) and (2) makes it much less useful than having all
3, but it's still useful in its own for helping people understand exactly which
physical operators were fused into a single codegen stage (as opposed to
assuming adjacent codegen'd operators are always in the same codegen stage).
The `SortMergeJoin` case was something that I really wished we had such an
ID readily available in the explain output. I had learned the hacky
implementation of SMJ the hard way...
With (3) and the new proposal of reserving `references[0]` for the
codegenStageId, I'm sure it'll be useful for some of your use cases (especially
codegen-related development), too. Do you have any use cases off the top of
your head, or any suggestions as to whether or not such an ID makes sense in
general?
Thanks!
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
