[
https://issues.apache.org/jira/browse/HIVE-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
翟玉勇 updated HIVE-16102:
-----------------------
Description:
# [~ashutoshc] realized that the implementation of GROUPING__ID in Hive was not
returning values as specified by SQL standard and other execution engines.
After digging into this, I found out that the implementation was bogus, as
internally it was changing between big-endian/little-endian representation of
GROUPING__ID indistinctly, and in some cases conversions in both directions
were cancelling each other.
In the documentation in
https://cwiki.apache.org/confluence/display/Hive/Enhanced+Aggregation,+Cube,+Grouping+and+Rollup
we can already find the problem, even if we did not spot it at first.
{quote}
The following query: SELECT key, value, GROUPING__ID, count(\*) from T1 GROUP
BY key, value WITH ROLLUP
will have the following results.
| NULL | NULL | 0 | 6 |
| 1 | NULL | 1 | 2 |
| 1 | NULL | 3 | 1 |
| 1 | 1 | 3 | 1 |
...
{quote}
Observe that value for GROUPING__ID in first row should be `3`, while for third
and fourth rows, it should be `0`.
was:
[~ashutoshc] realized that the implementation of GROUPING__ID in Hive was not
returning values as specified by SQL standard and other execution engines.
After digging into this, I found out that the implementation was bogus, as
internally it was changing between big-endian/little-endian representation of
GROUPING__ID indistinctly, and in some cases conversions in both directions
were cancelling each other.
In the documentation in
https://cwiki.apache.org/confluence/display/Hive/Enhanced+Aggregation,+Cube,+Grouping+and+Rollup
we can already find the problem, even if we did not spot it at first.
{quote}
The following query: SELECT key, value, GROUPING__ID, count(\*) from T1 GROUP
BY key, value WITH ROLLUP
will have the following results.
| NULL | NULL | 0 | 6 |
| 1 | NULL | 1 | 2 |
| 1 | NULL | 3 | 1 |
| 1 | 1 | 3 | 1 |
...
{quote}
Observe that value for GROUPING__ID in first row should be `3`, while for third
and fourth rows, it should be `0`.
> Grouping sets do not conform to SQL standard
> --------------------------------------------
>
> Key: HIVE-16102
> URL: https://issues.apache.org/jira/browse/HIVE-16102
> Project: Hive
> Issue Type: Bug
> Components: Operators, Parser
> Affects Versions: 1.3.0, 2.2.0
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Critical
> Fix For: 2.3.0
>
> Attachments: HIVE-16102.01.patch, HIVE-16102.02.patch,
> HIVE-16102.patch
>
>
> # [~ashutoshc] realized that the implementation of GROUPING__ID in Hive was
> not returning values as specified by SQL standard and other execution engines.
> After digging into this, I found out that the implementation was bogus, as
> internally it was changing between big-endian/little-endian representation of
> GROUPING__ID indistinctly, and in some cases conversions in both directions
> were cancelling each other.
> In the documentation in
> https://cwiki.apache.org/confluence/display/Hive/Enhanced+Aggregation,+Cube,+Grouping+and+Rollup
> we can already find the problem, even if we did not spot it at first.
> {quote}
> The following query: SELECT key, value, GROUPING__ID, count(\*) from T1 GROUP
> BY key, value WITH ROLLUP
> will have the following results.
> | NULL | NULL | 0 | 6 |
> | 1 | NULL | 1 | 2 |
> | 1 | NULL | 3 | 1 |
> | 1 | 1 | 3 | 1 |
> ...
> {quote}
> Observe that value for GROUPING__ID in first row should be `3`, while for
> third and fourth rows, it should be `0`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
