[
https://issues.apache.org/jira/browse/SPARK-26858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773381#comment-16773381
]
Hyukjin Kwon commented on SPARK-26858:
--------------------------------------
Oh, I see. Sorry there was misunderstanding. I think you're right.
All the ways are different from Python side, and gapplyCollect workaround is
pretty easy.
So, I was wondering if we need to fix it for now .. what I tried is 1. way. I
haven't tried other ways.
1. way looked minimised way and easy (but hacky) For 2. and 3., I am not sure
because it looks pretty different from Python side and I guess it needs
considerable codes..
> Vectorized gapplyCollect, Arrow optimization in native R function execution
> ---------------------------------------------------------------------------
>
> Key: SPARK-26858
> URL: https://issues.apache.org/jira/browse/SPARK-26858
> Project: Spark
> Issue Type: Sub-task
> Components: SparkR, SQL
> Affects Versions: 3.0.0
> Reporter: Hyukjin Kwon
> Assignee: Hyukjin Kwon
> Priority: Major
>
> Unlike gapply, gapplyCollect requires additional ser/de steps because it can
> omit the schema, and Spark SQL doesn't know the return type before actually
> execution happens.
> In original code path, it's done via using binary schema. Once gapply is done
> (SPARK-26761). we can mimic this approach in vectorized gapply to support
> gapplyCollect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
