hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashutosh Chauhan (JIRA)" <>
Subject [jira] [Commented] (HIVE-4197) Bring windowing support inline with SQL Standard
Date Mon, 18 Mar 2013 20:37:15 GMT


Ashutosh Chauhan commented on HIVE-4197:

bq. Standard Compliance: we defer from the SQL standard here (Partition/Order spec), which
only allows expressions to be Column References.
I think we can keep allowing expressions. This is more powerful, subsumes column reference
only and I don't see any confusion arising because of this.

bq. the Sql Standard allows boundary amount to be any expression of type Unsigned Int. We
are only allowing this to be a constant.
We are more restrictive than standard. But thats fine for now, we can improve on this later.

bq. : we don’t plan to support this feature (window frame exclusion) in release 1.
Yeah.. lets defer this to later release.

In section 2, I didn't get the concept of source window spec and thereby subsequent points.
Can you give an example in form of queries? That will help me formulate my opinion.

bq.  How do we achieve this stable order? Any suggestions.
This implies we must enforce secondary sort in reduce sink, otherwise order of values for
that key in reducer is unspecified. This effectively means that we are inserting an order
spec. Since in this case, user has not specified an order spec, doing ordering on partitioning
column is reasonable. I believe this is already the case in current implementation. Although
this forces us to forgo some optimizations (predicate pushdown) but thats fine for first release.
Later on, we can remember when we are introducing ordering ourselves vs when user has asked
for it, to give those optimization rules a chance to fire. 

bq. FOLLOWING unsigned int NULL ANY ??
I am also not clear what to do this in corner case. I think throwing an error is reasonable.

bq. Specification of a Range based Window: is not based on the Sort expression
I think here we don't have a luxury to deviate from standard on this one. As you have noted
this might be confusing. Better to remove it and be standard compliant. 

bq. • Notion of UDAFs that shouldn’t have a Window Frame: Rank, Dense_Rank, Percent_Rank,
Cume_Dist, Lead, Lag are configured this way.
I think its fine to keep existing behavior. Can't think of a use case where defining a window
frame for these functions making sense.

bq. Notion of Lead/Lag UDFs usable as arguments in UDAFs:
I think we can keep this since it serves useful use case. Though if it is burdensome to implement
or results in umaintainable code, I would prefer to remove it. So, I will leave this decision
upto you.
> Bring windowing support inline with SQL Standard
> ------------------------------------------------
>                 Key: HIVE-4197
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: PTF-Windowing
>            Reporter: Harish Butani
>         Attachments: WindowingSpecification.pdf
> The current behavior defers from the Standard in several significant places.
> Please review attached doc; there are still a few open issues. Once we agree on the behavior,
can proceed with fixing the implementation.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message