SORT_MERGE_JOIN on non-leading key: server-side sorting

Hello, I'm running Phoenix 4.13 on AWS EMR and getting the following EXPLAIN plan: Table: *CREATE TABLE salted ( keyA BIGINT NOT NULL, keyB BIGINT NOT NULL, val SMALLINT, CONSTRAINT pk PRIMARY KEY (keyA, keyB))SALT_BUCKETS = 64;* EXPLAIN: *EXPLAINSELECT /*+ USE_SORT_MERG

Re: SORT_MERGE_JOIN on non-leading key: server-side sorting

gt; latest Phoenix-4.13 package and testing it again? Thank you! > > > Thanks, > Maryann > > On Tue, May 8, 2018 at 12:24 PM, Gerald Sangudi > wrote: > >> Hello, >> >> I'm running Phoenix 4.13 on AWS EMR and getting the following EXPLAIN >> pla

Re: SORT_MERGE_JOIN on non-leading key: server-side sorting

Hi Maryann, Following up again -- I ran EXPLAIN on 4.13.1 and saw the same behavior, a sort on the RHS. Is it possible for you to try it on 4.13.1? Thanks, Gerald On Fri, May 11, 2018 at 10:52 AM, Gerald Sangudi wrote: > Hi Maryann, > > Thanks for verifying against latest. However,

Re: SORT_MERGE_JOIN on non-leading key: server-side sorting

will try it right away. >> >> On Wed, May 16, 2018 at 9:40 AM Gerald Sangudi >> wrote: >> >>> Hi Maryann, >>> >>> Following up again -- I ran EXPLAIN on 4.13.1 and saw the same behavior, >>> a sort on the RHS. Is it possible for you

Re: SORT_MERGE_JOIN on non-leading key: server-side sorting

OPLE"); >> myTableUpsertStmt.setString(3, "Z990"); >> myTableUpsertStmt.setBoolean(4, false); >> myTableUpsertStmt.execute(); >> conn.commit(); >> >> String query1 = "SELECT /*+ USE_SORT_MERGE_JOIN*/ COUNT(*)\n" + >> "FROM " + peopleT

Hash aggregation

Hello, Does Phoenix provide hash aggregation? If not, is it on the roadmap, or should I file a ticket? We have aggregation queries that do not require sorted results. For example, this EXPLAIN plan shows a CLIENT SORT. *CREATE TABLE unsalted ( keyA BIGINT NOT NULL, keyB BIGINT NOT NU

Re: Hash aggregation

t; Thanks, > Marynn > > On Fri, May 18, 2018 at 10:57 AM, Gerald Sangudi > wrote: > >> Hello, >> >> Does Phoenix provide hash aggregation? If not, is it on the roadmap, or >> should I file a ticket? We have aggregation queries that do not require >&g

Re: Hash aggregation

Hello, Any guidance or thoughts on the thread below? Thanks, Gerald On Fri, May 18, 2018 at 11:39 AM, Gerald Sangudi wrote: > Maryann, > > Can Phoenix provide hash aggregation on the client side? Are there design > / implementation reasons not to, or should I file a tic

Re: Hash aggregation

oup-by > can still be tolerable if there aren’t many distinct keys. So yes, please > open a JIRA for implementing hash aggregation on client side. Thank you! > > > Thanks, > Maryann > > On Tue, May 22, 2018 at 10:50 AM Gerald Sangudi > wrote: > >> Hel

Re: Hash aggregation

Hi Maryann and James, Any further guidance on PHOENIX-4751 <https://issues.apache.org/jira/browse/PHOENIX-4751>? Thanks, Gerald On Wed, May 23, 2018 at 11:00 AM, Gerald Sangudi wrote: > Hi Maryann, > > I filed PHOENIX-4751 <https://issues.apache.org/jira/browse/PHOENIX-

Re: Hash aggregation

Thanks James. Looking into that. Gerald On Thu, Jun 14, 2018 at 6:30 AM, James Taylor wrote: > Hi Gerald, > No further suggestions than my comments on the JIRA. Maybe a good next > step would be a patch? > Thanks, > James > > On Tue, Jun 12, 2018 at 8:15 PM, Gerald Sang

Re: Hash aggregation

Hello all, I've submitted a patch for this issue: https://github.com/apache/phoenix/pull/308 The JIRA ticket is https://issues.apache.org/jira/browse/PHOENIX-4751 Thanks, Gerald On Thu, Jun 14, 2018 at 8:33 AM, Gerald Sangudi wrote: > Thanks James. Looking into that. > > Geral

Re: Hash aggregation

Hi folks, Any idea of when this might be reviewed? I realize there are many open tasks. Thanks, Gerald On Mon, Jul 2, 2018 at 1:54 PM, Gerald Sangudi wrote: > Hello all, > > I've submitted a patch for this issue: https://github.com/ > apache/phoenix/pull/308 > > T

Re: Hash aggregation

Hi folks, I've received a couple of reviews and applied some of the feedback. Is there any way to know when this pull request will be merged? Thanks, Gerald On Mon, Jul 9, 2018 at 9:36 AM, Gerald Sangudi wrote: > Hi folks, > > Any idea of when this might be reviewed? I realize

Re: Null array elements with joins

Hello all, Any suggestions or pointers on the issue below? Projecting array elements works when not using joins, and does not work when we use hash joins. Is there an issue with the ProjectionCompiler for joins? I have not been able to isolate the specific cause, and would appreciate any pointers

Re: Null array elements with joins

Mon, Aug 13, 2018 at 11:08 AM, Gerald Sangudi > wrote: > >> Hello all, >> >> Any suggestions or pointers on the issue below? >> >> Projecting array elements works when not using joins, and does not work >> when we use hash joins. Is there an issue with

Salting based on partial rowkeys

Hello folks, We have a requirement for salting based on partial, rather than full, rowkeys. My colleague Mike Polcari has identified the requirement and proposed an approach. I found an already-open JIRA ticket for the same issue: https://issues.apache.org/jira/browse/PHOENIX-4757. I can provide

Re: Salting based on partial rowkeys

Hi folks, Any thoughts or feedback on this? Thanks, Gerald On Mon, Sep 10, 2018 at 1:56 PM, Gerald Sangudi wrote: > Hello folks, > > We have a requirement for salting based on partial, rather than full, > rowkeys. My colleague Mike Polcari has identified the requirement and &

Re: Salting based on partial rowkeys

> were used to avoid hotspot, in other words, HBase as a storage engine can't >> support hash partition. >> >> -------- >>Jaanai Zhang >>Best regards! >> >> >> >> Gerald Sangudi 于2018年9月13日周四 下午1