t; Best regards,
> Sumit
>
> --
> *From:* Maryann Xue <maryann@gmail.com>
> *To:* "user@phoenix.apache.org" <user@phoenix.apache.org>; Sumit Nigam <
> sumit_o...@yahoo.com>
> *Sent:* Wednesday, October 5, 2016 11:27 AM
> *Subject:* Re:
oo.com>
Sent: Wednesday, October 5, 2016 11:27 AM
Subject: Re: Hash join confusion
Not sure if it's related, coz your DDL does not have DESC columns, but we do
have a sort-merge-join bug fix in 4.8.0:
https://issues.apache.org/jira/browse/PHOENIX-2894.
Otherwise could you please just
ith time-out (and
> memory issue), so I switched to sort-merge. But sort-merge is missing data
> randomly. So, as of now I am not sure what is the issue with sort-merge
> join.
>
> Hash join does not miss any data but has the issue of not fitting in
> memory (the actual issue
: Sumit Nigam <sumit_o...@yahoo.com>
To: "user@phoenix.apache.org" <user@phoenix.apache.org>
Sent: Wednesday, October 5, 2016 12:13 AM
Subject: Re: Hash join confusion
Thanks Maryann.
I will share the details in a few hours.
Under heavy load scenario, the default
ache.org>
Sent: Tuesday, October 4, 2016 10:04 PM
Subject: Re: Hash join confusion
Hi Sumit,
Thank you for the update! Would you mind sharing the queries and their plans,
as well as the DDL for both the data tables and the index?
And just to confirm, you are saying hash joins are
" <user@phoenix.apache.org>
Sent: Sunday, October 2, 2016 5:30 AM
Subject: Re: Hash join confusion
So if either or both sides of a sort-merge-join will have to be sorted simply
depends on whether this side is already ordered on the join key.
So far we don't have any documentat
to interpret explain plan?
Thanks,Sumit
From: Maryann Xue <maryann@gmail.com>
To: Sumit Nigam <sumit_o...@yahoo.com>
Cc: "user@phoenix.apache.org" <user@phoenix.apache.org>
Sent: Thursday, September 29, 2016 11:03 AM
Subject: Re: Hash join confusion
e.org" <user@phoenix.apache.org>; Sumit Nigam <
> sumit_o...@yahoo.com>
> *Sent:* Wednesday, September 28, 2016 11:36 PM
> *Subject:* Re: Hash join confusion
>
> Yes, Sumit, the sub-query will get cached in hash join. Are you using
> multi-tenancy for these tab
ent: Wednesday, September 28, 2016 11:36 PM
Subject: Re: Hash join confusion
Yes, Sumit, the sub-query will get cached in hash join. Are you using
multi-tenancy for these tables? If yes, you might want to checkout Phoenix 4.7
or 4.8, since a related bug fix got in the 4.7 release.
https://i
Nigam <sumit_o...@yahoo.com>
> *To:* Users Mail List Phoenix <user@phoenix.apache.org>
> *Sent:* Tuesday, September 27, 2016 9:17 PM
> *Subject:* Hash join confusion
>
> Hi,
>
> I am using hbase 1.1 with phoenix 4.6.
>
> I have a table with row key as (current_
rn ON more verbose explain plan? Like, seeing number
of bytes, rows that each step results in?
Thanks,Sumit
From: Sumit Nigam <sumit_o...@yahoo.com>
To: Users Mail List Phoenix <user@phoenix.apache.org>
Sent: Tuesday, September 27, 2016 9:17 PM
Subject: Hash join confusion
Hi
Hi,
I am using hbase 1.1 with phoenix 4.6.
I have a table with row key as (current_timestamp, id) which is salted and
index on (id). This table has ~3 million records.
I have a query like given below.
SELECT ID, CURRENT_TIMESTAMP, from TBL
as a inner join (
12 matches
Mail list logo
