You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@spark.apache.org by "Hyukjin Kwon (JIRA)" <ji...@apache.org> on 2019/02/12 08:40:00 UTC

[jira] [Created] (SPARK-26858) Vectorized gapplyCollect, Arrow optimization in native R function execution

Hyukjin Kwon created SPARK-26858:
------------------------------------

             Summary: 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


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. 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: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org