Re: anyone relying on hadoop1 still?

Just a curiosity..what is the difference between hbase on hadoop1 or hadoop2 from a functional point of view? Does HBase on hadoop2 (Hoya?) rely on YARN features? On Tue, Sep 23, 2014 at 8:15 PM, James Taylor jamestay...@apache.org wrote: We'll definitely remove hadoop1 support from 4.x, as

Subqueries: Missing LPAREN

Hi, Is it possible to run sub-queries with Phoenix? Something like this: select * from metadata n where L = 1 AND R = (select max(R) from metadata z where n.A = z.A); Goel is to get all lignes where L=1 and R=max. Field A is the key. Thanks, JM

View composite key?

Hi, Is it possible to create a view on and existing HBase table and describe the composite key? I don't see anything about that in the doc http://phoenix.apache.org/views.html but it also doesn't say that it's not possible. Would like to do something like that: CREATE VIEW t1 ( USER

Re: View composite key?

Hi JM, Sure, you'd do that like this: CREATE VIEW t1 ( USER unsigned_long, ID unsigned_long, VERSION unsigned_long, f1.A unsigned_long, f1.R unsigned_long, f1.L unsigned_long, f1.W unsigned_long, f1.P bigint, f1.N varchar, f1.E varchar, f1.S unsigned_long, f1.M

Re: View composite key?

Oh nice! Thanks for this example! JM 2014-09-24 11:50 GMT-04:00 James Taylor jamestay...@apache.org: Hi JM, Sure, you'd do that like this: CREATE VIEW t1 ( USER unsigned_long, ID unsigned_long, VERSION unsigned_long, f1.A unsigned_long, f1.R unsigned_long, f1.L unsigned_long,

Re: Upper limit on SALT_BUCKETS?

The salt byte is the first byte in your row key and that's the max value for a byte (i.e. it'll be 0-255). On Wed, Sep 24, 2014 at 10:12 AM, Krishna research...@gmail.com wrote: Hi, According to Phoenix documentation Phoenix provides a way to transparently salt the row key with a salting

Re: Upper limit on SALT_BUCKETS?

Thanks... any plans of raising number of bytes for salt value? On Wed, Sep 24, 2014 at 10:22 AM, James Taylor jamestay...@apache.org wrote: The salt byte is the first byte in your row key and that's the max value for a byte (i.e. it'll be 0-255). On Wed, Sep 24, 2014 at 10:12 AM, Krishna

Re: Upper limit on SALT_BUCKETS?

Would you be able to talk about your use case a bit and explain why you'd need this to be higher? Thanks, James On Wednesday, September 24, 2014, Krishna research...@gmail.com wrote: Thanks... any plans of raising number of bytes for salt value? On Wed, Sep 24, 2014 at 10:22 AM, James Taylor

Re: JOIN and limit

Hi Abe, The expected behavior should be pushing the LIMIT to a (since it's left outer join) while checking the limit again against the final joined results. But it does not work as expected, it should be bug. Could you please verify it and report an issue with a test case attached? Thanks,

Recursive queries?

Hi, We have something like this that we want to translate into Phoenix (snippet): RETURN QUERY WITH RECURSIVE first_level AS ( -- non-recursive term ( SELECT a.id AS id FROM asset a WHERE a.parent_id = p_id AND TYPE = 2 ) UNION -- Recursive Term SELECT a.id AS id FROM

Re: Getting InsufficientMemoryException

Hi Vijay, I think here the query plan is scanning table *CUSTOMER_3 *while joining the other two tables at the same time, which means the region server memory for Phoenix should be large enough to hold 2 tables together and you also need to expect some memory expansion for java objects. Do

Re: Upper limit on SALT_BUCKETS?

50 Region Servers for 100 TB such that each RS serves 10 regions (500 regions). At this stage, we haven't evaluated the impact on query latency when running with fewer regions, for ex., 50 RS and 250 regions. On Wed, Sep 24, 2014 at 11:50 AM, James Taylor jamestay...@apache.org wrote: Would