[
https://issues.apache.org/jira/browse/HIVE-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605597#comment-13605597
]
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: https://issues.apache.org/jira/browse/HIVE-4197
> 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: http://www.atlassian.com/software/jira
