Github user HyukjinKwon commented on the issue:
https://github.com/apache/spark/pull/21537
Yea, yea. I understand. I wasn't trying to say the severity of effect by
introducing AnalysisBarrier wasn't trivial. True, I understand it is not an
easy job. Thank you Reynold for that. Yea, also I don't mean to say we should
just go ahead without sufficient discussion. Wanted to point out that there are
positive aspects of the effort and try about AnalysisBarrier too. It wasn't all
bad in a way.
> The reason why we did not merge this PR is that we are doubting this is
the right thing to do. @rednaxelafx
If that's true, the concerns should be mentioned here and discussed. Was
there a discussion about it in the community and did I miss it? I would
appreciate if we can talk here.
> Instead of reinventing a compiler, how about letting the compiler
internal expert (in our community, we have @kiszk) to lead the effort and offer
a design for this.
If there is a design concern for that and better suggestion, let's file a
JIRA. I want to see the problem, concerns and possible suggestions as well.
Yup, I got that it might be better for someone who has some expertise in
that area but I was thinking that they should purely based upon the community
work primarily - in that way, it looked reasonable @viirya goes ahead since
it's basically his work. If not, to me I don't see any particular one is
preferred.
Just wanted to point out that the baseline is open for anyone not for
specific persons. If anyone is willing to do this, anyone is welcome to go
ahead. So, primarily they should voluntarily join in without other factors.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
