diff options
| author | Wenchen Fan <wenchen@databricks.com> | 2016-04-20 00:44:02 -0700 |
|---|---|---|
| committer | Reynold Xin <rxin@databricks.com> | 2016-04-20 00:44:02 -0700 |
| commit | 7abe9a6578a99f4df50040d5cfe083c389c7b97f (patch) | |
| tree | 59f4ae404f2a0de4fae55da0849103999f87446b /sql/hive-thriftserver | |
| parent | 14869ae64eb27830179d4954a5dc3e0a1e1330b4 (diff) | |
| download | spark-7abe9a6578a99f4df50040d5cfe083c389c7b97f.tar.gz spark-7abe9a6578a99f4df50040d5cfe083c389c7b97f.tar.bz2 spark-7abe9a6578a99f4df50040d5cfe083c389c7b97f.zip | |
[SPARK-9013][SQL] generate MutableProjection directly instead of return a function
`MutableProjection` is not thread-safe and we won't use it in multiple threads. I think the reason that we return `() => MutableProjection` is not about thread safety, but to save the costs of generating code when we need same but individual mutable projections.
However, I only found one place that use this [feature](https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/Window.scala#L122-L123), and comparing to the troubles it brings, I think we should generate `MutableProjection` directly instead of return a function.
Author: Wenchen Fan <wenchen@databricks.com>
Closes #7373 from cloud-fan/project.
Diffstat (limited to 'sql/hive-thriftserver')
0 files changed, 0 insertions, 0 deletions