e> drop table T11;
OK
Time taken: 0.79 seconds
hive> drop table T12;
OK
Time taken: 0.35 seconds
Anyone has idea why dropping a table could take up to 60 seconds?
---
[cid:image001.jpg@01CE92B5.CB034C90]
Dima Machlin, Big Data Architect
15 Abba Eban
p by effect the "Load back 1 hashtable file from tmp" step in
any way?
Thanks in advance for any answers/comments.
---
[cid:image001.jpg@01CE92B5.CB034C90]
Dima Machlin, Big Data Architect
15 Abba Eban Blvd. PO Box 4125, Herzliya 46140 IL
P: +972
You are using the default Derby metastore?
There shouldn’t be any problem opening multiple connections to MySQL, Oracle or
Postgres.
From: Amjad ALSHABANI [mailto:ashshab...@gmail.com]
Sent: Wednesday, May 28, 2014 11:42 AM
To: user@hive.apache.org
Subject: HiveServer2 with Hive CLI
Hello every
hive.server2.thrift.port=26006
The connection is made from JDBC.
Executing the same procedure from the CLI generates all the expected logging.
From: Dima Machlin [mailto:dima.mach...@pursway.com]
Sent: Wednesday, May 21, 2014 5:06 PM
To: user@hive.apache.org
Subject: HiveServer2 VS HiveServer1 Logging
Hi all,
It seems that for some reason HS2 outputs far less logging than HS1 in hive
0.12 for example, starting HS1 in the following way : hive --service hiveserver
and executing show tables produces this :
14/04/30 17:14:16 [pool-1-thread-2] INFO service.HiveServer: Running the query:
show tabl
Wed, May 14, 2014 at 9:38 AM, Dima Machlin
mailto:dima.mach...@pursway.com>> wrote:
Hi,
Starting the metastore (Hive 0.12) service there is a WARNING
[main] WARN bonecp.BoneCPConfig: Max Connections < 1. Setting to 20
What does this setting mean? Max connections from hive servers to the
Hi,
Starting the metastore (Hive 0.12) service there is a WARNING
[main] WARN bonecp.BoneCPConfig: Max Connections < 1. Setting to 20
What does this setting mean? Max connections from hive servers to the metastore?
How can this be changed?
Thanks.
Look here :
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-RelationalOperators
If one the sides of != is NULL, the results is NULL (not true, but not false
also)
From: Blaine Elliott [mailto:bla...@chegg.com]
Sent: Wednesday, February 05, 2014 8:50 PM
To:
Counting in your case isn't practical as the expected count can be greater than
the amount of rows which isn't possible using the count function.
What you can do is multiply the amount of rows by the amount of columns.
This can be done using a different table (like dual if you'd create it)
Let as
Use join instead :
select as_of_dt as as_of_dt, max_feed_key as max_feed_key, min_feed_key as
min_feed_key
from table feed_key_temp join ( select max(feed_key) mfk from summ_table ) st
where max_fed_key > mfk
group by as_of_dt ;
This join is done without an "ON" clause. This way, all the rows in
hive-log4j.properties which is
set to :
hive.log.file=hive.log
Trying to set it also as the previous doesn't help as ${hive.query.id} resolves
to nothing.
Any advice appreciated.
-------
[cid:image001.jpg@01CE92B5.CB034C90]
Dima Machlin, Big Data Architect
Pursway.com<http://www.pursway.com/>
<>
Hi Nirmal,
I recently performed a similar upgrade process from Hive 0.7 to Hive 0.10
It seems that as some bugs in the 0.7 versions are solved in newer release,
some new bugs appear.
I'd recommend to setup a test environment running the newer version of Hive,
and testing the SQLs you are running
12 matches
Mail list logo
