hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (JIRA)" <>
Subject [jira] [Commented] (HIVE-784) Support uncorrelated subqueries in the WHERE clause
Date Mon, 14 Oct 2013 21:51:42 GMT


Phabricator commented on HIVE-784:

ashutoshc has requested changes to the revision "HIVE-784 [jira] Support uncorrelated subqueries
in the WHERE clause".

  Design looks good. Mostly implementation related comments.

  ql/src/java/org/apache/hadoop/hive/ql/parse/IdentifiersParser.g:391 It would be nicer if
instead of two rules for IN / NOT IN if we could just have one rule, which can conditionally
generate TOK_SUBQUERY_OP_NOTIN / TOK_SUBQUERY_OP_IN token. Not a big deal, but would be nice
to have since that makes grammar bit more succinct.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ You mentioned in
comment above that we don't support nested / recursive subq, but I don't see a check for that.
Perhaps, its there but I missed it.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Thanks for detailed
comments. Very helpful!
  ql/src/java/org/apache/hadoop/hive/ql/parse/ There should exactly
one subq currently. If so, will be good to add a note for it.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Since, OR is not supported,
It will be good to generate an error message here if OR is encountered.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Same logic exists
in SemanticAnalyzer::doPhase1GetAllAggregations, perhaps we can create a util method in ParseUtils,
instead of repeating code here.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ If you mark this as transient,
you probably wont need to write Kryo serializer for this.
  ql/src/java/org/apache/hadoop/hive/ql/exec/ I dont think its required.
We should probably mark all usage of instances of ASTNodeOrigin as transient.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ This should never be the
case. Shall we throw an exception here, instead of silently returning?
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Is this allowed by standard
that subq predicate may refer to Outer? If yes, than in future perhaps we can add this predicate
as a conjunct for outer query.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Is this need to be .equals()
check here instead of == ?
  ql/src/java/org/apache/hadoop/hive/ql/parse/ It will be good to add a
comment, why we need to have True condition here, instead? Probably, because plan gen fails
later while generating rest of filter plan.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Good to name this
method as validateAndRewriteAST() ?
  ql/src/java/org/apache/hadoop/hive/ql/parse/ Quite a bit of this
code is repeated from genJoinTree(), seems like atleast some bits could be refactored out
of genJoinTree() which this method can make use of.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ name sqOperator is
misleading here, topOp perhaps ?
  ql/src/java/org/apache/hadoop/hive/ql/parse/ This is not an operator in
classic Hive sense. Perhaps, SubqASTcontainer or something else.
  ql/src/java/org/apache/hadoop/hive/ql/parse/ SubQueryType instead of SubQueryOperatorType




To: JIRA, ashutoshc, hbutani

> Support uncorrelated subqueries in the WHERE clause
> ---------------------------------------------------
>                 Key: HIVE-784
>                 URL:
>             Project: Hive
>          Issue Type: New Feature
>          Components: Query Processor
>            Reporter: Ning Zhang
>            Assignee: Harish Butani
>         Attachments: D13443.1.patch, HIVE-784.1.patch.txt, HIVE-784.2.patch, SubQuerySpec.pdf,
> Hive currently only support views in the FROM-clause, some Facebook use cases suggest
that Hive should support subqueries such as those connected by IN/EXISTS in the WHERE-clause.

This message was sent by Atlassian JIRA

View raw message