hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gopal V (JIRA)" <>
Subject [jira] [Commented] (HIVE-16418) Allow HiveKey to skip some bytes for comparison
Date Thu, 13 Apr 2017 13:14:41 GMT


Gopal V commented on HIVE-16418:

bq. The basic idea is to store all the non-comparable bytes at the beginning of HiveKey.

That's the part that confuses me, what are in these bytes?

>From the standard perspective, I usually use Postgres as a "good interpretation" - Postgres
*does* not store the TZ information provided by the user after parsing, so it never has to
handle 2 different serialized timestamps which are equivalent (but not equal as serialized

{code} Time Stamps

For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated
Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit
time zone specified is converted to UTC using the appropriate offset for that time zone. If
no time zone is stated in the input string, then it is assumed to be in the time zone indicated
by the system's timezone parameter, and is converted to UTC using the offset for the timezone
When a timestamp with time zone value is output, it is always converted from UTC to the current
timezone zone, and displayed as local time in that zone.

if Hive follows a similar interpretation of the standard, the BinarySortable and LazyBinary
representations of the Timestamp_with_timezone are identical to the Timestamp implementation
that already exists.

> Allow HiveKey to skip some bytes for comparison
> -----------------------------------------------
>                 Key: HIVE-16418
>                 URL:
>             Project: Hive
>          Issue Type: New Feature
>            Reporter: Rui Li
>            Assignee: Rui Li
>         Attachments: HIVE-16418.1.patch
> The feature is required when we have to serialize some fields and prevent them from being
used in comparison, e.g. HIVE-14412.

This message was sent by Atlassian JIRA

View raw message