Uh oh!
There was an error while loading. Please reload this page.
[SPARK-34819][SQL] MapType supports comparable semantics - #32552
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
SparkQA
commented
May 14, 2021
Kubernetes integration test unable to build dist. exiting with code: 1 |
SparkQA
commented
May 14, 2021
Test build #138562 has finished for PR 32552 at commit
|
SparkQA
commented
May 15, 2021
Kubernetes integration test starting |
SparkQA
commented
May 15, 2021
Kubernetes integration test status failure |
SparkQA
commented
May 15, 2021
Test build #138570 has finished for PR 32552 at commit
|
7d6ab65 to
539a1e6CompareSparkQA
commented
May 15, 2021
Kubernetes integration test starting |
SparkQA
commented
May 15, 2021
Kubernetes integration test status failure |
SparkQA
commented
May 15, 2021
Kubernetes integration test starting |
SparkQA
commented
May 15, 2021
Kubernetes integration test status failure |
SparkQA
commented
May 15, 2021
Test build #138573 has finished for PR 32552 at commit
|
SparkQA
commented
May 15, 2021
Test build #138575 has finished for PR 32552 at commit
|
3c8b19a to
d08942fCompareSparkQA
commented
May 16, 2021
Kubernetes integration test unable to build dist. exiting with code: 1 |
SparkQA
commented
May 16, 2021
Test build #138579 has finished for PR 32552 at commit
|
d22a6e1 to
38e42c4CompareSparkQA
commented
May 16, 2021
Kubernetes integration test starting |
SparkQA
commented
May 16, 2021
Kubernetes integration test status failure |
maropu
commented
May 16, 2021
SparkQA
commented
Jun 29, 2021
Test build #140384 has finished for PR 32552 at commit
|
maropu
commented
Jun 30, 2021
retest this please |
SparkQA
commented
Jun 30, 2021
Kubernetes integration test starting |
SparkQA
commented
Jun 30, 2021
Kubernetes integration test status success |
SparkQA
commented
Jun 30, 2021
Test build #140411 has finished for PR 32552 at commit
|
maropu
commented
Jul 12, 2021
retest this please |
SparkQA
commented
Jul 12, 2021
Kubernetes integration test starting |
SparkQA
commented
Jul 12, 2021
Kubernetes integration test status success |
SparkQA
commented
Jul 12, 2021
Test build #140889 has finished for PR 32552 at commit
|
SparkQA
commented
Jul 16, 2021
Kubernetes integration test starting |
SparkQA
commented
Jul 16, 2021
Kubernetes integration test status success |
SparkQA
commented
Jul 16, 2021
Test build #141123 has finished for PR 32552 at commit
|
maropu
commented
Jul 16, 2021
retest this please |
SparkQA
commented
Jul 16, 2021
Kubernetes integration test starting |
SparkQA
commented
Jul 16, 2021
Kubernetes integration test starting |
SparkQA
commented
Jul 16, 2021
Kubernetes integration test status success |
SparkQA
commented
Jul 16, 2021
Kubernetes integration test status success |
SparkQA
commented
Jul 16, 2021
Test build #141144 has finished for PR 32552 at commit
|
SparkQA
commented
Aug 26, 2021
Kubernetes integration test starting |
SparkQA
commented
Aug 26, 2021
Kubernetes integration test status failure |
We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
rekbun
commented
Jul 31, 2024
Folks, what is the state of this PR? Do we expect to make progress on this? |
What changes were proposed in this pull request?
This PR proposes to support comparable semantics for map types.
NOTE: This PR is the rework of #31967(@WangGuangxin)/#15970(@hvanhovell).
The approach of the PR is similar to
NormalizeFloatingNumbersand it has the same restriction; in the plan optimizing phase, a new rule namedNormalizeMapsinserts an expressionSortMapKeysto make sure two maps having the same key value pairs but with different key ordering are equal (e.g., Map('a' -> 1, 'b' -> 2) should equal to Map('b' -> 2, 'a' -> 1). As for aggregates, this rule is applied in the physical planning phase because all the grouping exprs are not extracted during the logical phase (This is the same restriction withNormalizeFloatingNumbers).The major differences from
NormalizeFloatingNumbersare as follows;EqualTo,GreaterThan, ...) andIn/InSetin a plan (NormalizeFloatingNumbersis applied only into theEqualTocomparison in a join plan, an equi-join).normalizerecursively and just adds aSortMapKeysexpr just on each top-level expr (e.g., top-level grouping expr and left/right side expr of binary comparisons).SortOrders in sort-related plans.For sorting map entries, I reused the array ordering logic (See:
MapType.compareandCodegenContext.genComp) because keys and values in map entries follow the array format; it checks if key arrays in two maps are the same first, an then check if value arrays are the same.NOTE: Adding duplicate
SortMapKeysexprs in a binary comparison tree is a known issue; for example, in a query below,MapType's column,a, is sorted twice;But, I don't have a smart idea to avoid it in this PR for now. Probably, I think common subexpression elimination in filter plans can solve it, but Spark does not have the optimization now. (Fro more details, see the previous @viirya PR: #30565).
Why are the changes needed?
To improve map usability.
Does this PR introduce any user-facing change?
Yes, a user can use map-typed data in GROUP BY, ORDER BY, and PARTITION BY in WINDOW clauses.
How was this patch tested?
Add unit tests.