[jira] [Created] (HIVE-20636) Improve number of null values estimation after outer join

[Jesus Camacho Rodriguez (JIRA)]

Jesus Camacho Rodriguez created HIVE-20636:
--

 Summary: Improve number of null values estimation after outer join
 Key: HIVE-20636
 URL: https://issues.apache.org/jira/browse/HIVE-20636
 Project: Hive
  Issue Type: Bug
  Components: Statistics
Affects Versions: 4.0.0
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HIVE-20635) VectorizedOrcAcidRowBatchReader doesn't filter delete events for original files

[Eugene Koifman (JIRA)]

Eugene Koifman created HIVE-20635:
-

 Summary: VectorizedOrcAcidRowBatchReader doesn't filter delete 
events for original files
 Key: HIVE-20635
 URL: https://issues.apache.org/jira/browse/HIVE-20635
 Project: Hive
  Issue Type: Improvement
  Components: Transactions
Affects Versions: 3.0.0
Reporter: Eugene Koifman


this is a followup to HIVE-16812 which adds support for delete event filtering 
for splits from native acid files

need to add the same for {{OrcSplit.isOriginal()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HIVE-20634) DirectSQL does not retry in ORM mode while getting partitions by filter

[Karthik Manamcheri (JIRA)]

Karthik Manamcheri created HIVE-20634:
-

 Summary: DirectSQL does not retry in ORM mode while getting 
partitions by filter
 Key: HIVE-20634
 URL: https://issues.apache.org/jira/browse/HIVE-20634
 Project: Hive
  Issue Type: Bug
Reporter: Karthik Manamcheri
Assignee: Karthik Manamcheri


The code path for getting partitions by filter is as follows,
{code:java}
  protected List getPartitionsByFilterInternal(..) {
   ...
  @Override
  protected boolean canUseDirectSql(GetHelper> ctx) throws 
MetaException 
 {
return directSql.generateSqlFilterForPushdown(ctx.getTable(), tree, 
filter);
  }
   ...
  }
{code}
If directSql.generateSqlFilterForPushdown throws an exception, we should be 
returning false from canUseDirectSql instead of propagating the exception. The 
propagation of exception causes the whole query to fail, instead of retrying 
with JDO.

We should have code such as
{code:java}
  @Override
  protected boolean canUseDirectSql(GetHelper ctx) throws 
MetaException {
try {
  return directSql.generateSqlFilterForPushdown(ctx.getTable(), 
exprTree, filter);
} catch (final MetaException me) {
  return false;
}
  }
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HIVE-20633) Incorrect column lineage: each output column has input from *all columns* of the input table

[Madhan Neethiraj (JIRA)]

Madhan Neethiraj created HIVE-20633:
---

 Summary: Incorrect column lineage: each output column has input 
from *all columns* of the input table
 Key: HIVE-20633
 URL: https://issues.apache.org/jira/browse/HIVE-20633
 Project: Hive
  Issue Type: New Feature
  Components: HiveServer2
Affects Versions: 1.2.2
Reporter: Madhan Neethiraj


Column lineage details made available to post hook is incorrect for certain 
queries - like the following INSERT:

{noformat}
CREATE TABLE source_tbl(col_001 INT, col_002 INT, col_003 INT);

CREATE TABLE target_tbl(col_001 INT, col_002 INT, col_003 INT);

INSERT INTO target_tbl SELECT v1.col_001, v1.col_002, v1.col_003 FROM (SELECT 
col_001, col_002, col_003, ROW_NUMBER() OVER() AS r_num FROM source_tbl) v1;

{noformat}

Below are the details of the lineage given to post hooks (like Atlas hook) via 
HookContext.getLinfo(). It contains 3 entries, one for each target table 
column. Note the dependency for each column has all columns of the source 
tables.

{noformat}
DependencyKey=default.target_tbl:FieldSchema(name:col_001, type:int, 
comment:null)
Dependency=[SCRIPT]
   [default.source_tbl(src):FieldSchema(name:col_001, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_002, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_003, type:int, 
comment:null),

default.source_tbl(src):FieldSchema(name:BLOCK__OFFSET__INSIDE__FILE, 
type:bigint, comment:),
default.source_tbl(src):FieldSchema(name:INPUT__FILE__NAME, 
type:string, comment:),
default.source_tbl(src):FieldSchema(name:ROW__ID, 
type:struct, comment:)
   ];
 
DependencyKey=default.target_tbl:FieldSchema(name:col_002, type:int, 
comment:null)
Dependency=[SCRIPT]
   [default.source_tbl(src):FieldSchema(name:col_001, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_002, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_003, type:int, 
comment:null),

default.source_tbl(src):FieldSchema(name:BLOCK__OFFSET__INSIDE__FILE, 
type:bigint, comment:),
default.source_tbl(src):FieldSchema(name:INPUT__FILE__NAME, 
type:string, comment:),
default.source_tbl(src):FieldSchema(name:ROW__ID, 
type:struct, comment:)
   ];
 
DependencyKey=default.target_tbl:FieldSchema(name:col_003, type:int, 
comment:null)
Dependency=[SCRIPT]
   [default.source_tbl(src):FieldSchema(name:col_001, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_002, type:int, 
comment:null),
default.source_tbl(src):FieldSchema(name:col_003, type:int, 
comment:null),

default.source_tbl(src):FieldSchema(name:BLOCK__OFFSET__INSIDE__FILE, 
type:bigint, comment:),
default.source_tbl(src):FieldSchema(name:INPUT__FILE__NAME, 
type:string, comment:),
default.source_tbl(src):FieldSchema(name:ROW__ID, 
type:struct, comment:)
   ];
{noformat}


When INSERT statement doesn't include "ROW_NUMBER() OVER() AS r_num", the 
lineage details look correct. 




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hive pull request #438: HIVE-20632: Query with get_splits UDF fails if mater...

[sankarh]

GitHub user sankarh opened a pull request:

https://github.com/apache/hive/pull/438

HIVE-20632: Query with get_splits UDF fails if materialized view is created 
on queried table.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sankarh/hive HIVE-20632

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hive/pull/438.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #438


commit 8356b2ea7d6c699e3a5057b34e5752b2c871aafc
Author: Sankar Hariappan 
Date:   2018-09-25T16:31:41Z

HIVE-20632: Query with get_splits UDF fails if materialized view is created 
on queried table.




---

[jira] [Created] (HIVE-20632) Query with get_splits UDF fails if materialized view is created on queried table.

[Sankar Hariappan (JIRA)]

Sankar Hariappan created HIVE-20632:
---

 Summary: Query with get_splits UDF fails if materialized view is 
created on queried table. 
 Key: HIVE-20632
 URL: https://issues.apache.org/jira/browse/HIVE-20632
 Project: Hive
  Issue Type: Bug
  Components: HiveServer2, Materialized views, Standalone Metastore, UDF
Affects Versions: 4.0.0, 3.2.0
Reporter: Sankar Hariappan
Assignee: Sankar Hariappan


Scenario:
 # Create ACID table t1 and insert few rows.
 # Create materialized view mv as select a from t1 where a > 5;
 # Run get_split query "select get_splits( select a from t1 where a > 5); – 
This fails with AssertionError.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Review Request 68710: HIVE-20544: TOpenSessionReq logs password and username

[Andrew Sherman via Review Board]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/68710/#review208993
---




service-rpc/pom.xml
Lines 156 (patched)


This change works (I assume) but it is fragile. What if the generated code 
changes? Maybe consider 
1. adding a simple java unit test that proves that the password is not in 
toString() output 
2. adding a comment to the generated code so that readers can see that 
somethign funny is happening


- Andrew Sherman


On Sept. 24, 2018, 2:01 p.m., Karen Coppage wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/68710/
> ---
> 
> (Updated Sept. 24, 2018, 2:01 p.m.)
> 
> 
> Review request for hive and Laszlo Pinter.
> 
> 
> Bugs: HIVE-20544
> https://issues.apache.org/jira/browse/HIVE-20544
> 
> 
> Repository: hive-git
> 
> 
> Description
> ---
> 
> TOpenSessionReq, if client protocol is unset, both username and password are 
> logged. Logging a password is a security risk. This patch would hide it with 
> asterisks.
> 
> 
> Diffs
> -
> 
>   service-rpc/pom.xml d6a07a55bc 
>   
> service-rpc/src/gen/thrift/gen-javabean/org/apache/hive/service/rpc/thrift/TOpenSessionReq.java
>  3195e704f3 
> 
> 
> Diff: https://reviews.apache.org/r/68710/diff/5/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> HIVE-20544.3.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/24/9f8ef0d8-22df-40cf-a311-56335d88516a__HIVE-20544.3.patch
> HIVE-20544.3.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/24/afdfc085-cc06-4a47-81f8-499029719bd0__HIVE-20544.3.patch
> 
> 
> Thanks,
> 
> Karen Coppage
> 
>

Re: Review Request 68683: Add new configuration to set the size of the global compile lock

[denys kuzmenko via Review Board]

> On Sept. 24, 2018, 11:14 p.m., Peter Vary wrote:
> > Hi Denys,
> > 
> > Could you please think a little about separating the Manager/Factory and 
> > the tryAcquire mess?
> > 
> > Incomplete thoughts, but I had to run
> > 
> > Thanks, and sorry :(
> > Peter

Please review new patch. Really appreciate your and Zoltan's suggestions, now 
code looks much better.


> On Sept. 24, 2018, 11:14 p.m., Peter Vary wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/CompileLockManager.java
> > Lines 130 (patched)
> > 
> >
> > nit: I do prefer creating static final variables at the begining of the 
> > class, or at the first use. Do not create a new patch because of this, but 
> > if you have to do a new one please move the declaration up to the line ~51

done!


> On Sept. 24, 2018, 11:14 p.m., Peter Vary wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Line 1854 (original), 1849-1850 (patched)
> > 
> >
> > This still makes me itching...
> > I think we should separate the Manager / Factory and the actual lock 
> > object.
> > I would prefer the following:
> > - CompileLockManager should create the lock object
> > - Use the lock object as Zoltan suggested (try-with-resources)
> > - If we decide to keep tryAcquire - can we do it as a wrapper around 
> > the tryLock method

Please review new path! Thank you!


- denys


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/68683/#review208968
---


On Sept. 25, 2018, 10:19 a.m., denys kuzmenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/68683/
> ---
> 
> (Updated Sept. 25, 2018, 10:19 a.m.)
> 
> 
> Review request for hive, Zoltan Haindrich, Zoltan Haindrich, Naveen Gangam, 
> and Peter Vary.
> 
> 
> Bugs: HIVE-20535
> https://issues.apache.org/jira/browse/HIVE-20535
> 
> 
> Repository: hive-git
> 
> 
> Description
> ---
> 
> When removing the compile lock, it is quite risky to remove it entirely.
> 
> It would be good to provide a pool size for the concurrent compilation, so 
> the administrator can limit the load
> 
> 
> Diffs
> -
> 
>   common/src/java/org/apache/hadoop/hive/conf/HiveConf.java 8c39de3e77 
>   ql/src/java/org/apache/hadoop/hive/ql/Driver.java 737debd2ad 
>   ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLock.java PRE-CREATION 
>   ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLockFactory.java 
> PRE-CREATION 
>   ql/src/test/org/apache/hadoop/hive/ql/CompileLockTest.java PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/68683/diff/6/
> 
> 
> Testing
> ---
> 
> Added CompileLockTest
> 
> 
> File Attachments
> 
> 
> HIVE-20535.1.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/13/41f5a84a-70e5-4882-99c1-1cf98c4364e4__HIVE-20535.1.patch
> HIVE-20535.14.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/25/335b0f4b-ea94-41d4-881a-ec8bb870a376__HIVE-20535.14.patch
> HIVE-20535.14.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/25/a92b6da2-eeba-46ee-9409-162653826172__HIVE-20535.14.patch
> HIVE-20535.14.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/25/9db4cf76-9188-48fb-bd3d-5b28e43a791b__HIVE-20535.14.patch
> 
> 
> Thanks,
> 
> denys kuzmenko
> 
>

Re: Review Request 68683: Add new configuration to set the size of the global compile lock

[denys kuzmenko via Review Board]

> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > I'm not sure but I feel that it would be probably simpler to add something 
> > which covers some reentrant-s and semaphores.
> > It feels like this lock handling is a littlebit scattered around...I think 
> > it would be better to have them outside of the Driver class.
> 
> denys kuzmenko wrote:
> moved logic to CompileLockManager

splitted and extracted functionality of CompileLock and CompileLockFactory


> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Lines 247 (patched)
> > 
> >
> > I'm not sure we gain anything by having these strings in a static block 
> > - they are only used as log messages at debug level..
> 
> denys kuzmenko wrote:
> It's a clean code practice (String literals)

refactored


> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Lines 252 (patched)
> > 
> >
> > final
> 
> denys kuzmenko wrote:
> there is conditional logic, default value is serializableCompileLock;

Fixed.


> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Lines 271 (patched)
> > 
> >
> > it seems to me that this class is not the lock itself...it instead the 
> > "thing that locks"...
> > 
> > but getInstance() gives the feeling that it's something like a 
> > singleton...this is a little bit confusing to me
> 
> denys kuzmenko wrote:
> externalized to CompileLockManager class

refactored, added Factory and Lock


> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Lines 380 (patched)
> > 
> >
> > my first comment was: why do we use 2 locks now?
> > 
> > I now understand why...I feel that probably trying to replace the 
> > existing logic with a decent one which could handle all these cases would 
> > make it more straight.
> > If you don't think that would be appropriate - that's okay; just drop 
> > this issue...
> 
> denys kuzmenko wrote:
> it's just a first steps in compile lock refactoring.

New locks could be created with CompileLockFactory.


> On Sept. 17, 2018, 9:15 a.m., Zoltan Haindrich wrote:
> > ql/src/java/org/apache/hadoop/hive/ql/Driver.java
> > Line 1860 (original), 2017 (patched)
> > 
> >
> > I think it would be better to use try-with-resouces instead of manual 
> > control...that would also take care of the unlock/release/etc as well
> > 
> > I feel that it's easier to follow - if a lock has a scope..
> 
> denys kuzmenko wrote:
> I would have to remember the result of tryAcquire method (aquired lock or 
> not) and supply it to AutoClosable.close(){if(locked) lock.unlock()} . I 
> think it would complicate the logic.

Fixed


- denys


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/68683/#review208625
---


On Sept. 25, 2018, 10:19 a.m., denys kuzmenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/68683/
> ---
> 
> (Updated Sept. 25, 2018, 10:19 a.m.)
> 
> 
> Review request for hive, Zoltan Haindrich, Zoltan Haindrich, Naveen Gangam, 
> and Peter Vary.
> 
> 
> Bugs: HIVE-20535
> https://issues.apache.org/jira/browse/HIVE-20535
> 
> 
> Repository: hive-git
> 
> 
> Description
> ---
> 
> When removing the compile lock, it is quite risky to remove it entirely.
> 
> It would be good to provide a pool size for the concurrent compilation, so 
> the administrator can limit the load
> 
> 
> Diffs
> -
> 
>   common/src/java/org/apache/hadoop/hive/conf/HiveConf.java 8c39de3e77 
>   ql/src/java/org/apache/hadoop/hive/ql/Driver.java 737debd2ad 
>   ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLock.java PRE-CREATION 
>   ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLockFactory.java 
> PRE-CREATION 
>   ql/src/test/org/apache/hadoop/hive/ql/CompileLockTest.java PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/68683/diff/6/
> 
> 
> Testing
> ---
> 
> Added CompileLockTest
> 
> 
> File Attachments
> 
> 
> HIVE-20535.1.patch
>   
> https://reviews.apache.org/media/uploaded/files/2018/09/13/41f5a84a-70e5-4882-99c1-1cf98c4364e4__HIVE-20535.1.patch
> HIVE-20535.14.patch
>   
> 

Re: Review Request 68683: Add new configuration to set the size of the global compile lock

[denys kuzmenko via Review Board]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/68683/
---

(Updated Sept. 25, 2018, 10:19 a.m.)


Review request for hive, Zoltan Haindrich, Zoltan Haindrich, Naveen Gangam, and 
Peter Vary.


Bugs: HIVE-20535
https://issues.apache.org/jira/browse/HIVE-20535


Repository: hive-git


Description
---

When removing the compile lock, it is quite risky to remove it entirely.

It would be good to provide a pool size for the concurrent compilation, so the 
administrator can limit the load


Diffs (updated)
-

  common/src/java/org/apache/hadoop/hive/conf/HiveConf.java 8c39de3e77 
  ql/src/java/org/apache/hadoop/hive/ql/Driver.java 737debd2ad 
  ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLock.java PRE-CREATION 
  ql/src/java/org/apache/hadoop/hive/ql/lock/CompileLockFactory.java 
PRE-CREATION 
  ql/src/test/org/apache/hadoop/hive/ql/CompileLockTest.java PRE-CREATION 


Diff: https://reviews.apache.org/r/68683/diff/6/

Changes: https://reviews.apache.org/r/68683/diff/5-6/


Testing
---

Added CompileLockTest


File Attachments (updated)


HIVE-20535.1.patch
  
https://reviews.apache.org/media/uploaded/files/2018/09/13/41f5a84a-70e5-4882-99c1-1cf98c4364e4__HIVE-20535.1.patch
HIVE-20535.14.patch
  
https://reviews.apache.org/media/uploaded/files/2018/09/25/335b0f4b-ea94-41d4-881a-ec8bb870a376__HIVE-20535.14.patch
HIVE-20535.14.patch
  
https://reviews.apache.org/media/uploaded/files/2018/09/25/a92b6da2-eeba-46ee-9409-162653826172__HIVE-20535.14.patch
HIVE-20535.14.patch
  
https://reviews.apache.org/media/uploaded/files/2018/09/25/9db4cf76-9188-48fb-bd3d-5b28e43a791b__HIVE-20535.14.patch


Thanks,

denys kuzmenko

Review Request 68836: HIVE-17917 VectorizedOrcAcidRowBatchReader.computeOffsetAndBucket optimization

[Saurabh Seth]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/68836/
---

Review request for hive and Eugene Koifman.


Bugs: HIVE-17917
https://issues.apache.org/jira/browse/HIVE-17917


Repository: hive-git


Description
---

VectorizedOrcAcidRowBatchReader.computeOffsetAndBucket optimization() 
computation is currently (after HIVE-17458) is done once per split. It could 
instead be done once per file (since the result is the same for each split of 
the same file) and passed along in OrcSplit


Diffs
-

  ql/src/java/org/apache/hadoop/hive/ql/io/orc/OrcInputFormat.java f34f393fb8 
  ql/src/java/org/apache/hadoop/hive/ql/io/orc/OrcSplit.java bce7977929 
  
ql/src/java/org/apache/hadoop/hive/ql/io/orc/VectorizedOrcAcidRowBatchReader.java
 1841cfaa2e 
  ql/src/test/org/apache/hadoop/hive/ql/io/orc/TestInputOutputFormat.java 
208aeb5b1f 
  ql/src/test/queries/clientpositive/acid_vectorization_original.q 5082aedf90 
  ql/src/test/results/clientpositive/llap/acid_vectorization_original.q.out 
99c741c7bd 


Diff: https://reviews.apache.org/r/68836/diff/1/


Testing
---


Thanks,

Saurabh Seth

[GitHub] hive pull request #437: HIVE-20631 : Hive returns 20011 error code for re-tr...

[maheshk114]

GitHub user maheshk114 opened a pull request:

https://github.com/apache/hive/pull/437

HIVE-20631 : Hive returns 20011 error code for re-triable error



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/maheshk114/hive HIVE-20631

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hive/pull/437.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #437


commit 7cc8ff99f9d44d17fedd16cf5f7a5c2414713fda
Author: Mahesh Kumar Behera 
Date:   2018-09-25T09:41:19Z

HIVE-20631 : Hive returns 20011 error code for re-triable error




---

[jira] [Created] (HIVE-20631) Hive returns 20011 error code for re-triable error

[mahesh kumar behera (JIRA)]

mahesh kumar behera created HIVE-20631:
--

 Summary: Hive returns 20011 error code for re-triable error
 Key: HIVE-20631
 URL: https://issues.apache.org/jira/browse/HIVE-20631
 Project: Hive
  Issue Type: Bug
  Components: repl
Affects Versions: 4.0.0
Reporter: mahesh kumar behera
Assignee: mahesh kumar behera
 Fix For: 4.0.0


In case of network issue .repl load is returning non retry-able error code. 

The scenario is 
1. While copying the file, repl load found that source is not reachable and 
went for copy retry.
2. While retying, getting file checksum failed due to network issue and thus 
its assumed that the source file is not present. So in the next retry copy is 
tried from cm path.
3. In the next retry, network is recovered and it in cm path no file was found. 
This will cause return of non retry-able error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HIVE-20630) Limit don't apply on Distribute clause

[albertoramon (JIRA)]

albertoramon created HIVE-20630:
---

 Summary: Limit don't apply on Distribute clause
 Key: HIVE-20630
 URL: https://issues.apache.org/jira/browse/HIVE-20630
 Project: Hive
  Issue Type: Bug
  Components: Query Planning
Affects Versions: 2.3.1
Reporter: albertoramon


In this code, the limit=1000 doesn't have expected result

```sql
INSERT OVERWRITE TABLE myNewTable partition (col1, col2)
select 
. . . 
from  mySource
distribute by (floor(myColumn/2646 - + 1)/ 20 ) sort by merchant_fk
limit 1000;

select count (1) from ft_informes_trafico_stats_hdfs_arp;
>> 3001
```



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hive pull request #436: HIVE-20629 : Hive incremental replication fails with...

[maheshk114]

GitHub user maheshk114 opened a pull request:

https://github.com/apache/hive/pull/436

HIVE-20629 : Hive incremental replication fails with events missing error 
if database is kept idle for more than an hour

…

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/maheshk114/hive HIVE-20629

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hive/pull/436.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #436


commit 3baec79980d91face1ebb4355fe3848e8bf3cca0
Author: Mahesh Kumar Behera 
Date:   2018-09-25T03:34:48Z

HIVE-20629 : Hive incremental replication fails with events missing error 
if database is kept idle for more than an hour




---