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
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 unsigned_l
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,
Oh nice! Thanks for this example!
JM
2014-09-24 11:50 GMT-04:00 James Taylor :
> 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,
>"
Hi,
According to Phoenix documentation
"Phoenix provides a way to transparently salt the row key with a salting
> byte for a particular table. You need to specify this in table creation
> time by specifying a table property “SALT_BUCKETS” with a value from 1 to
> 256"
Is 256 the max value that
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 wrote:
> Hi,
>
> According to Phoenix documentation
>
>> "Phoenix provides a way to transparently salt the row key with a salting
>> byte for a part
Thanks... any plans of raising number of bytes for salt value?
On Wed, Sep 24, 2014 at 10:22 AM, James Taylor
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 wrote:
> > Hi,
> >
>
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 wrote:
> Thanks... any plans of raising number of bytes for salt value?
>
>
> On Wed, Sep 24, 2014 at 10:22 AM, James Taylor > wrote:
>
>> Th
Hi JM,
Think this sub-query feature is covered by PHOENIX-1168, for which a
check-in is expected very soon.
Thanks,
Maryann
On Wed, Sep 24, 2014 at 9:06 AM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:
> Hi,
>
> Is it possible to run sub-queries with Phoenix? Something like this:
>
>
Hi Maryann,
We have already spotted PHOENIX-1168 and tracking it ;) Thanks for the
patch!
We have already downloaded it and will give it a try.
JM
2014-09-24 15:39 GMT-04:00 Maryann Xue :
> Hi JM,
>
> Think this sub-query feature is covered by PHOENIX-1168, for which a
> check-in is expected v
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,
Mary
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 first_lev
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 yo
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
wrote:
> Would you be able to talk abo
Hey JM,
We'd like to support all of SQL-99 eventually, so based on that, it's
on our roadmap. Like most open source projects, we'd look for a
volunteer to take this on - it certainly meets the criteria of being
interesting.
I think priority-wise, it's lower than most of the join work
identified on
15 matches
Mail list logo