Jenkins build is back to normal : Hive-trunk-h0.20 #605

[Apache Hudson Server]

See 

[jira] Updated: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[Namit Jain (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Namit Jain updated HIVE-2040:
-

  Resolution: Fixed
Hadoop Flags: [Reviewed]
  Status: Resolved  (was: Patch Available)

Committed. Thanks Yongqiang

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
> Attachments: HIVE-2040.1.patch, HIVE-2040.2.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2039) remove hadoop version check from hive cli shell script

[Ning Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ning Zhang updated HIVE-2039:
-

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed. Thanks Joydeep!

> remove hadoop version check from hive cli shell script
> --
>
> Key: HIVE-2039
> URL: https://issues.apache.org/jira/browse/HIVE-2039
> Project: Hive
>  Issue Type: Improvement
>  Components: CLI
>Reporter: Joydeep Sen Sarma
>Assignee: Joydeep Sen Sarma
> Fix For: 0.8.0
>
> Attachments: HIVE-2039.1.patch
>
>
> looking at cli startup times - one thing i noticed is that the version check 
> in execHiveCmd.sh consumes 0.5-1s of wall-clock time (depending on where hive 
> is installed).
> AFAIK - hive doesn't support versions less than 20 right now - and this check 
> is only to check if version is less than 20. So we should be able to safely 
> take it out. please comment if that is not the case.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HIVE-1694) Accelerate GROUP BY execution using indexes

[John Sichi (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005461#comment-13005461
 ] 

John Sichi commented on HIVE-1694:
--

Hi Prajakta,

Review Board is self-service...you can create yourself an account and then 
follow the steps here:

http://wiki.apache.org/hadoop/Hive/HowToContribute#Review_Process


> Accelerate GROUP BY execution using indexes
> ---
>
> Key: HIVE-1694
> URL: https://issues.apache.org/jira/browse/HIVE-1694
> Project: Hive
>  Issue Type: New Feature
>  Components: Indexing, Query Processor
>Affects Versions: 0.7.0
>Reporter: Nikhil Deshpande
>Assignee: Prajakta Kalmegh
> Attachments: HIVE-1694.1.patch.txt, HIVE-1694.2.patch.txt, 
> HIVE-1694.3.patch.txt, HIVE-1694_2010-10-28.diff, demo_q1.hql, demo_q2.hql
>
>
> The index building patch (Hive-417) is checked into trunk, this JIRA issue 
> tracks supporting indexes in Hive compiler & execution engine for SELECT 
> queries.
> This is in ref. to John's comment at
> https://issues.apache.org/jira/browse/HIVE-417?focusedCommentId=12884869&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12884869
> on creating separate JIRA issue for tracking index usage in optimizer & query 
> execution.
> The aim of this effort is to use indexes to accelerate query execution (for 
> certain class of queries). E.g.
> - Filters and range scans (already being worked on by He Yongqiang as part of 
> HIVE-417?)
> - Joins (index based joins)
> - Group By, Order By and other misc cases
> The proposal is multi-step:
> 1. Building index based operators, compiler and execution engine changes
> 2. Optimizer enhancements (e.g. cost-based optimizer to compare and choose 
> between index scans, full table scans etc.)
> This JIRA initially focuses on the first step. This JIRA is expected to hold 
> the information about index based plans & operator implementations for above 
> mentioned cases. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[Namit Jain (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005458#comment-13005458
 ] 

Namit Jain commented on HIVE-2040:
--

+1

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
> Attachments: HIVE-2040.1.patch, HIVE-2040.2.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[He Yongqiang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

He Yongqiang updated HIVE-2040:
---

Status: Patch Available  (was: Open)

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
> Attachments: HIVE-2040.1.patch, HIVE-2040.2.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[He Yongqiang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

He Yongqiang updated HIVE-2040:
---

Attachment: HIVE-2040.2.patch

change to use a do{}while(); just in case the user set an incorrect retry 
number.

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
> Attachments: HIVE-2040.1.patch, HIVE-2040.2.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Hive-trunk-h0.20 #604

[Apache Hudson Server]

See 

--
[...truncated 26784 lines...]
[junit] PREHOOK: type: CREATETABLE
[junit] POSTHOOK: query: create table testhivedrivertable (num int)
[junit] POSTHOOK: type: CREATETABLE
[junit] POSTHOOK: Output: default@testhivedrivertable
[junit] OK
[junit] PREHOOK: query: load data local inpath 
'
 into table testhivedrivertable
[junit] PREHOOK: type: LOAD
[junit] Copying data from 

[junit] Loading data to table default.testhivedrivertable
[junit] POSTHOOK: query: load data local inpath 
'
 into table testhivedrivertable
[junit] POSTHOOK: type: LOAD
[junit] POSTHOOK: Output: default@testhivedrivertable
[junit] OK
[junit] PREHOOK: query: select count(1) as cnt from testhivedrivertable
[junit] PREHOOK: type: QUERY
[junit] PREHOOK: Input: default@testhivedrivertable
[junit] PREHOOK: Output: 
file:/tmp/hudson/hive_2011-03-10_15-38-44_745_5504403048161218839/-mr-1
[junit] Total MapReduce jobs = 1
[junit] Launching Job 1 out of 1
[junit] Number of reduce tasks determined at compile time: 1
[junit] In order to change the average load for a reducer (in bytes):
[junit]   set hive.exec.reducers.bytes.per.reducer=
[junit] In order to limit the maximum number of reducers:
[junit]   set hive.exec.reducers.max=
[junit] In order to set a constant number of reducers:
[junit]   set mapred.reduce.tasks=
[junit] Job running in-process (local Hadoop)
[junit] Hadoop job information for null: number of mappers: 0; number of 
reducers: 0
[junit] 2011-03-10 15:38:47,821 null map = 100%,  reduce = 100%
[junit] Ended Job = job_local_0001
[junit] POSTHOOK: query: select count(1) as cnt from testhivedrivertable
[junit] POSTHOOK: type: QUERY
[junit] POSTHOOK: Input: default@testhivedrivertable
[junit] POSTHOOK: Output: 
file:/tmp/hudson/hive_2011-03-10_15-38-44_745_5504403048161218839/-mr-1
[junit] OK
[junit] PREHOOK: query: drop table testhivedrivertable
[junit] PREHOOK: type: DROPTABLE
[junit] PREHOOK: Input: default@testhivedrivertable
[junit] PREHOOK: Output: default@testhivedrivertable
[junit] POSTHOOK: query: drop table testhivedrivertable
[junit] POSTHOOK: type: DROPTABLE
[junit] POSTHOOK: Input: default@testhivedrivertable
[junit] POSTHOOK: Output: default@testhivedrivertable
[junit] OK
[junit] Hive history 
file=
[junit] PREHOOK: query: drop table testhivedrivertable
[junit] PREHOOK: type: DROPTABLE
[junit] POSTHOOK: query: drop table testhivedrivertable
[junit] POSTHOOK: type: DROPTABLE
[junit] OK
[junit] PREHOOK: query: create table testhivedrivertable (num int)
[junit] PREHOOK: type: CREATETABLE
[junit] POSTHOOK: query: create table testhivedrivertable (num int)
[junit] POSTHOOK: type: CREATETABLE
[junit] POSTHOOK: Output: default@testhivedrivertable
[junit] OK
[junit] PREHOOK: query: load data local inpath 
'
 into table testhivedrivertable
[junit] PREHOOK: type: LOAD
[junit] Copying data from 

[junit] Loading data to table default.testhivedrivertable
[junit] POSTHOOK: query: load data local inpath 
'
 into table testhivedrivertable
[junit] POSTHOOK: type: LOAD
[junit] POSTHOOK: Output: default@testhivedrivertable
[junit] OK
[junit] PREHOOK: query: select * from testhivedrivertable limit 10
[junit] PREHOOK: type: QUERY
[junit] PREHOOK: Input: default@testhivedrivertable
[junit] PREHOOK: Output: 
file:/tmp/hudson/hive_2011-03-10_15-38-49_366_6155685477151313105/-mr-1
[junit] POSTHOOK: query: select * from testhivedrivertable limit 10
[junit] POSTHOOK: type: QUERY
[junit] POSTHOOK: Input: default@testhivedrivertable
[junit] POSTHOOK: Output: 
file:/tmp/hudson/hive_2011-03-10_15-38-49_366_6155685477151313105/-mr-1
[junit] OK
[junit] PREHOOK: query: drop table testhivedrivertable
[junit] PREHOOK: type: DROPTABLE
[junit] PREHOOK: Input: default@testhivedrivertable
[junit] PREHOOK: Output: default@testhivedrivertable
[junit] POSTHOOK: query: drop table testhivedrivertable
[junit] POSTHOOK: type: DROPTABLE
[junit] POSTHOOK: Input: default@testhivedrivertable
[junit] POSTHOOK: Output: defaul

[jira] Updated: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[He Yongqiang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

He Yongqiang updated HIVE-2040:
---

Attachment: HIVE-2040.1.patch

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
> Attachments: HIVE-2040.1.patch
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2040) the retry logic in Hive's concurrency is not working correctly.

[He Yongqiang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

He Yongqiang updated HIVE-2040:
---

Summary: the retry logic in Hive's concurrency  is not working correctly.  
(was: the retry logic in Hive is not working.)

> the retry logic in Hive's concurrency  is not working correctly.
> 
>
> Key: HIVE-2040
> URL: https://issues.apache.org/jira/browse/HIVE-2040
> Project: Hive
>  Issue Type: Bug
>Reporter: He Yongqiang
>Assignee: He Yongqiang
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (HIVE-2040) the retry logic in Hive is not working.

[He Yongqiang (JIRA)]

the retry logic in Hive is not working.
---

 Key: HIVE-2040
 URL: https://issues.apache.org/jira/browse/HIVE-2040
 Project: Hive
  Issue Type: Bug
Reporter: He Yongqiang
Assignee: He Yongqiang




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HIVE-2030) isEmptyPath() to use ContentSummary cache

[He Yongqiang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005358#comment-13005358
 ] 

He Yongqiang commented on HIVE-2030:


running tests with the new patch

> isEmptyPath() to use ContentSummary cache
> -
>
> Key: HIVE-2030
> URL: https://issues.apache.org/jira/browse/HIVE-2030
> Project: Hive
>  Issue Type: Improvement
>Reporter: Siying Dong
>Assignee: Siying Dong
>Priority: Minor
> Attachments: HIVE-2030.1.patch, HIVE-2030.2.patch, HIVE-2030.3.patch
>
>
> addInputPaths() calls isEmptyPath() for every input path. Now every call is a 
> DFS namenode call. Making isEmptyPath() to use cached ContentSummary, we 
> should be able to avoid some namenode calls and reduce latency in the case of 
> multiple partitions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2030) isEmptyPath() to use ContentSummary cache

[Siying Dong (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Siying Dong updated HIVE-2030:
--

Attachment: HIVE-2030.3.patch

> isEmptyPath() to use ContentSummary cache
> -
>
> Key: HIVE-2030
> URL: https://issues.apache.org/jira/browse/HIVE-2030
> Project: Hive
>  Issue Type: Improvement
>Reporter: Siying Dong
>Assignee: Siying Dong
>Priority: Minor
> Attachments: HIVE-2030.1.patch, HIVE-2030.2.patch, HIVE-2030.3.patch
>
>
> addInputPaths() calls isEmptyPath() for every input path. Now every call is a 
> DFS namenode call. Making isEmptyPath() to use cached ContentSummary, we 
> should be able to avoid some namenode calls and reduce latency in the case of 
> multiple partitions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: hooks in metastore functions

[Ashutosh Chauhan]

Cool. I will prepare a patch and post on HIVE-2038.

Ashutosh
On Wed, Mar 9, 2011 at 16:59, John Sichi  wrote:
> Yeah, thinking about it more, they're likely to end up looking different.  
> The listener should cover most possible repository changes, whereas 
> HiveMetaHook is focused on a narrower set of object definitions.
>
> JVS
>
> On Mar 9, 2011, at 1:48 PM, Ashutosh Chauhan wrote:
>
>> It might be possible to extend and modify the HiveMetaHook interface.
>> But, I think keeping them separate is better because MetaHook and
>> MetaStoreListener are interfaces for two different functionalities.
>> MetaHook is for communicating with external system if there is a need
>> for it. MetaStoreListener observe changes on metastore and run some
>> logic in response to those changes. What do you think?
>>
>> Ashutosh
>>
>> On Wed, Mar 9, 2011 at 13:36, John Sichi  wrote:
>>> Couldn't we reuse HiveMetaHook for this new purpose (with an instance 
>>> loaded via global config vs associated with the table handler)?
>>>
>>> JVS
>>>
>>> On Mar 8, 2011, at 2:12 PM, Ashutosh Chauhan wrote:
>>>
 Hi all,

 I have a requirement that every time some change on metastore takes
 place, we have some logic which needs to be run. For example, if a new
 table is getting created in metastore I want to send a message to a
 message bus. Easiest way for this to work is to add the logic in
 createTable(). Control it by a hiveConf param and turn it off by
 default. Alternative way is via hooks. Have this extra logic in hook
 and then load and fire the hook if its available. Does anyone has an
 opinion which of these two is preferable. Second one requires new hook
 loading and execution logic. I am currently interested in four
 functions: createTable() dropTable() addPartition() dropPartition().
 Current, HiveMetaHook which exists in createTable() doesn't perfectly
 fit the bill, since it is fired only when user expresses it in his
 create table statement (i.e., if he has specified a storage handler)
 Instead I want to have this logic always run.
 If it is unclear, let me know, I can post the code  which can
 demonstrate my usecase.

 Ashutosh
>>>
>>>
>
>

[jira] Commented: (HIVE-2030) isEmptyPath() to use ContentSummary cache

[He Yongqiang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005234#comment-13005234
 ] 

He Yongqiang commented on HIVE-2030:


siying, can you update the patch?

> isEmptyPath() to use ContentSummary cache
> -
>
> Key: HIVE-2030
> URL: https://issues.apache.org/jira/browse/HIVE-2030
> Project: Hive
>  Issue Type: Improvement
>Reporter: Siying Dong
>Assignee: Siying Dong
>Priority: Minor
> Attachments: HIVE-2030.1.patch, HIVE-2030.2.patch
>
>
> addInputPaths() calls isEmptyPath() for every input path. Now every call is a 
> DFS namenode call. Making isEmptyPath() to use cached ContentSummary, we 
> should be able to avoid some namenode calls and reduce latency in the case of 
> multiple partitions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-2024) In Driver.execute(), mapred.job.tracker is not restored if one of the task fails.

[He Yongqiang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

He Yongqiang updated HIVE-2024:
---

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed. Thanks Siying!

> In Driver.execute(), mapred.job.tracker is not restored if one of the task 
> fails.
> -
>
> Key: HIVE-2024
> URL: https://issues.apache.org/jira/browse/HIVE-2024
> Project: Hive
>  Issue Type: Bug
>Reporter: Siying Dong
>Assignee: Siying Dong
> Attachments: HIVE-2024.1.patch
>
>
> If automatically one job is determined to run in local mode, and the task 
> fails with error code not 0, mapred.job.tracker will remain to be local and 
> might cause further problems.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Hive-trunk-h0.20 #603

[Apache Hudson Server]

See 

--
Started by timer
Building remotely on ubuntu1
FATAL: Unable to call fetch2. Invalid object ID 6395
java.lang.IllegalStateException: Unable to call fetch2. Invalid object ID 6395
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:268)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

[jira] Commented: (HIVE-1694) Accelerate GROUP BY execution using indexes

[Prajakta Kalmegh (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005045#comment-13005045
 ] 

Prajakta Kalmegh commented on HIVE-1694:


Hi John

Please find attached the patch with new index type support. We have also made 
changes to the our optimizer code to use count of indexed columns from this new 
index type (instead of computing the size(_offsets)). Can you please upload it 
for review on ReviewBoard?

Thanks.

> Accelerate GROUP BY execution using indexes
> ---
>
> Key: HIVE-1694
> URL: https://issues.apache.org/jira/browse/HIVE-1694
> Project: Hive
>  Issue Type: New Feature
>  Components: Indexing, Query Processor
>Affects Versions: 0.7.0
>Reporter: Nikhil Deshpande
>Assignee: Prajakta Kalmegh
> Attachments: HIVE-1694.1.patch.txt, HIVE-1694.2.patch.txt, 
> HIVE-1694.3.patch.txt, HIVE-1694_2010-10-28.diff, demo_q1.hql, demo_q2.hql
>
>
> The index building patch (Hive-417) is checked into trunk, this JIRA issue 
> tracks supporting indexes in Hive compiler & execution engine for SELECT 
> queries.
> This is in ref. to John's comment at
> https://issues.apache.org/jira/browse/HIVE-417?focusedCommentId=12884869&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12884869
> on creating separate JIRA issue for tracking index usage in optimizer & query 
> execution.
> The aim of this effort is to use indexes to accelerate query execution (for 
> certain class of queries). E.g.
> - Filters and range scans (already being worked on by He Yongqiang as part of 
> HIVE-417?)
> - Joins (index based joins)
> - Group By, Order By and other misc cases
> The proposal is multi-step:
> 1. Building index based operators, compiler and execution engine changes
> 2. Optimizer enhancements (e.g. cost-based optimizer to compare and choose 
> between index scans, full table scans etc.)
> This JIRA initially focuses on the first step. This JIRA is expected to hold 
> the information about index based plans & operator implementations for above 
> mentioned cases. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (HIVE-1694) Accelerate GROUP BY execution using indexes

[Prajakta Kalmegh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prajakta Kalmegh updated HIVE-1694:
---

Attachment: HIVE-1694.3.patch.txt

Patch with new index type support and optimizer code that uses the new index 
type.

> Accelerate GROUP BY execution using indexes
> ---
>
> Key: HIVE-1694
> URL: https://issues.apache.org/jira/browse/HIVE-1694
> Project: Hive
>  Issue Type: New Feature
>  Components: Indexing, Query Processor
>Affects Versions: 0.7.0
>Reporter: Nikhil Deshpande
>Assignee: Prajakta Kalmegh
> Attachments: HIVE-1694.1.patch.txt, HIVE-1694.2.patch.txt, 
> HIVE-1694.3.patch.txt, HIVE-1694_2010-10-28.diff, demo_q1.hql, demo_q2.hql
>
>
> The index building patch (Hive-417) is checked into trunk, this JIRA issue 
> tracks supporting indexes in Hive compiler & execution engine for SELECT 
> queries.
> This is in ref. to John's comment at
> https://issues.apache.org/jira/browse/HIVE-417?focusedCommentId=12884869&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12884869
> on creating separate JIRA issue for tracking index usage in optimizer & query 
> execution.
> The aim of this effort is to use indexes to accelerate query execution (for 
> certain class of queries). E.g.
> - Filters and range scans (already being worked on by He Yongqiang as part of 
> HIVE-417?)
> - Joins (index based joins)
> - Group By, Order By and other misc cases
> The proposal is multi-step:
> 1. Building index based operators, compiler and execution engine changes
> 2. Optimizer enhancements (e.g. cost-based optimizer to compare and choose 
> between index scans, full table scans etc.)
> This JIRA initially focuses on the first step. This JIRA is expected to hold 
> the information about index based plans & operator implementations for above 
> mentioned cases. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HIVE-1877) Add java_method() as a synonym for the reflect() UDF

[Amareshwari Sriramadasu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005034#comment-13005034
 ] 

Amareshwari Sriramadasu commented on HIVE-1877:
---

+1 Patch looks good

> Add java_method() as a synonym for the reflect() UDF
> 
>
> Key: HIVE-1877
> URL: https://issues.apache.org/jira/browse/HIVE-1877
> Project: Hive
>  Issue Type: Improvement
>  Components: UDF
>Affects Versions: 0.7.0
>Reporter: Carl Steinbach
>Assignee: Carl Steinbach
> Attachments: HIVE-1877.1.patch.txt, HIVE-1877.2.patch.txt
>
>
> HIVE-471 added the reflect() UDF which allows people to invoke static Java 
> methods from within HQL
> queries. In my opinion the name is confusing since it describes how the UDF 
> works instead of what
> it does. I propose changing the name of (or providing a synonym for) the UDF 
> to something like
>  'invoke_method' or 'java_method', or something similar. I'm open to 
> suggestions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HIVE-1095) Hive in Maven

[Amareshwari Sriramadasu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005024#comment-13005024
 ] 

Amareshwari Sriramadasu commented on HIVE-1095:
---

Gerrit, are you planning to regenerate the patch incorporating Carl's comments?

> Hive in Maven
> -
>
> Key: HIVE-1095
> URL: https://issues.apache.org/jira/browse/HIVE-1095
> Project: Hive
>  Issue Type: Task
>  Components: Build Infrastructure
>Affects Versions: 0.6.0
>Reporter: Gerrit Jansen van Vuuren
>Priority: Minor
> Attachments: HIVE-1095-trunk.patch, hiveReleasedToMaven.tar.gz
>
>
> Getting hive into maven main repositories
> Documentation on how to do this is on:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira