diff options
| author | Liang-Chi Hsieh <simonh@tw.ibm.com> | 2016-05-04 10:54:51 -0700 |
|---|---|---|
| committer | Davies Liu <davies.liu@gmail.com> | 2016-05-04 10:54:51 -0700 |
| commit | b85d21fb9dc3d498d9a10e065d254abde797efb6 (patch) | |
| tree | 50cf5f6c1b9e6252e010eec1bd7063bcbd24cbec /examples/src | |
| parent | d864c55cf8c92466336e796d0c98d83230e330af (diff) | |
| download | spark-b85d21fb9dc3d498d9a10e065d254abde797efb6.tar.gz spark-b85d21fb9dc3d498d9a10e065d254abde797efb6.tar.bz2 spark-b85d21fb9dc3d498d9a10e065d254abde797efb6.zip | |
[SPARK-14951] [SQL] Support subexpression elimination in TungstenAggregate
## What changes were proposed in this pull request?
We can support subexpression elimination in TungstenAggregate by using current `EquivalentExpressions` which is already used in subexpression elimination for expression codegen.
However, in wholestage codegen, we can't wrap the common expression's codes in functions as before, we simply generate the code snippets for common expressions. These code snippets are inserted before the common expressions are actually used in generated java codes.
For multiple `TypedAggregateExpression` used in aggregation operator, since their input type should be the same. So their `inputDeserializer` will be the same too. This patch can also reduce redundant input deserialization.
## How was this patch tested?
Existing tests.
Author: Liang-Chi Hsieh <simonh@tw.ibm.com>
Closes #12729 from viirya/subexpr-elimination-tungstenaggregate.
Diffstat (limited to 'examples/src')
0 files changed, 0 insertions, 0 deletions