[jira] [Commented] (PHOENIX-34) Insufficient memory exception on join when RHS rows count > 250K

[ https://issues.apache.org/jira/browse/PHOENIX-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897600#comment-13897600 ] James Taylor commented on PHOENIX-34: - Sure, let's lower it. It's typically memory tha

[jira] [Created] (PHOENIX-36) Parallel Scaling

Lars Hofhansl created PHOENIX-36: Summary: Parallel Scaling Key: PHOENIX-36 URL: https://issues.apache.org/jira/browse/PHOENIX-36 Project: Phoenix Issue Type: Bug Reporter: Lars H

[jira] [Commented] (PHOENIX-34) Insufficient memory exception on join when RHS rows count > 250K

[ https://issues.apache.org/jira/browse/PHOENIX-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897586#comment-13897586 ] Lars Hofhansl commented on PHOENIX-34: -- I think giving Phoenix much more than 10% by

[jira] [Updated] (PHOENIX-6) Support on duplicate key ignore construct

[ https://issues.apache.org/jira/browse/PHOENIX-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-6: --- Assignee: Haitao Yao > Support on duplicate key ignore construct > ---

[jira] [Commented] (PHOENIX-34) Insufficient memory exception on join when RHS rows count > 250K

[ https://issues.apache.org/jira/browse/PHOENIX-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897495#comment-13897495 ] James Taylor commented on PHOENIX-34: - That's why we made it configurable, [~lhofhansl

[jira] [Commented] (PHOENIX-6) Support on duplicate key ignore construct

[ https://issues.apache.org/jira/browse/PHOENIX-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897489#comment-13897489 ] James Taylor commented on PHOENIX-6: This could be done in two stages: first for UPSERT

[jira] [Commented] (PHOENIX-34) Insufficient memory exception on join when RHS rows count > 250K

[ https://issues.apache.org/jira/browse/PHOENIX-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897473#comment-13897473 ] Lars Hofhansl commented on PHOENIX-34: -- We should not give Phoenix 50% of the heap on

[jira] [Created] (PHOENIX-35) Perf test memory usage for indexes

James Taylor created PHOENIX-35: --- Summary: Perf test memory usage for indexes Key: PHOENIX-35 URL: https://issues.apache.org/jira/browse/PHOENIX-35 Project: Phoenix Issue Type: Bug Affects

[jira] [Created] (PHOENIX-34) Insufficient memory exception on join when RHS rows count > 250K

Mujtaba Chohan created PHOENIX-34: - Summary: Insufficient memory exception on join when RHS rows count > 250K Key: PHOENIX-34 URL: https://issues.apache.org/jira/browse/PHOENIX-34 Project: Phoenix

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Branches make sense where you are going to be making more changes along that same line. A branch for 4.0.0 implies that you are going to release a 4.0.0.1, 4.0.0.2, etc. (at least to me). By having a 4.0 branch, you *more* lean towards semantic versioning because along that same branch you can eas

Re: best development methodology for Apache git?

FYI, in case you're not following this on the general list, the INFRA guys have been working hard to improve the Github/Apache mail integration. If you link your Github user name with your Apache id by editing this file[1], when you open a pull requests on the Apache Github mirror, the dev list wil

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Personally I'd be in favor of 4.0.0 as this conveys the fact that we do semantic versioning. As usually I do not feel strongly about this. -- Lars From: James Taylor To: "dev@phoenix.incubator.apache.org" Sent: Monday, February 10, 2014 3:50 PM Subject: Re:

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

+1 Caveat that that 4.1, 4.2 lines should probably get their own branches. --- Jesse Yates @jesse_yates jyates.github.com On Mon, Feb 10, 2014 at 3:50 PM, James Taylor wrote: > Sure, 4.0 is fine. I think we can just tag our minor and point releases > instead of creating branche

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Sure, 4.0 is fine. I think we can just tag our minor and point releases instead of creating branches for them. On Mon, Feb 10, 2014 at 3:41 PM, Jeffrey Zhong wrote: > > James, how do you think the branch name 4.0 over 4.0.0? It mostly depends > on the naming convention. 4.0 seems better > unless

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

James, how do you think the branch name 4.0 over 4.0.0? It mostly depends on the naming convention. 4.0 seems better unless in the future we have branch like 4.0.1(or 4.0.##) > If you set up a job building against HBase trunk snapshots (and HBase remembers to publish those then > Jenkins

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Unlikely if 1.0 is going to be in a couple of months, unless volunteers step forward to do that big refactor tomorrow. Also, discussion of a change of that magnitude should definitely surface to dev@hbase. On Mon, Feb 10, 2014 at 2:33 PM, James Taylor wrote: > +1. That's a very good idea, Enis -

VOTE RESULT (WAS --> Re: VOTE: Accept the software grant by Salesforce)

Voting is now closed. This vote passes with 6 binding +1 votes and no 0 or -1 votes. Thank you to everyone who voted. Totals: +1: Michael Stack(*) Devaraj Das(*) Lars Hofhansl(*) James Taylor Mujtaba Chohan Enis Söztutar(*) Andrew Purtell(*) Eli Levine Jesse Yates Ramkrishna S Vasudevan Rajeshbab

[GitHub] incubator-phoenix pull request: Phoenix 10

Github user JamesRTaylor commented on the pull request: https://github.com/apache/incubator-phoenix/pull/2#issuecomment-34694910 Testing comment feature - only comments on the pull request are sent, not comments on lines.

[GitHub] incubator-phoenix pull request: Phoenix 10

Github user Humbedooh commented on the pull request: https://github.com/apache/incubator-phoenix/pull/2#issuecomment-34692410 Sorry to hijack this, just testing whether phoenix is getting these comments on their ML now. Ignore please

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

+1. That's a very good idea, Enis - for HBase 1.0 if possible. On Mon, Feb 10, 2014 at 2:28 PM, Enis Söztutar wrote: > Forgot to mention, there was some discussion about filter / coprocessors > versus plugins. It seems that coprocessors are doing both more user-facing > database trigger kind of

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Forgot to mention, there was some discussion about filter / coprocessors versus plugins. It seems that coprocessors are doing both more user-facing database trigger kind of functionality + some plugging into Hbase internals functionality. I think longer term, we should define different interfaces f

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Awesome work Jeffrey. Should we name the branch 4.0, instead of 4.0.0? It would be good to have a list of methods used by Phoenix to be identified and tagged in HBase so that at least future changes are not completely random. We might start with annotation InterfaceAudience.LimitedPrivate, so tha

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

On Mon, Feb 10, 2014 at 2:07 PM, James Taylor wrote: > Mujtaba - would it be > feasible to setup Jenkins builds for this branch as well? > Or, HBase 0.98 is really close to HBase trunk still. If you set up a job building against HBase trunk snapshots (and HBase remembers to publish those...) then

Re: What we are sending the Apache Board as our Feb. report

+1'ing from here for now. It seems that I do not have wiki edit permission. Enis On Sun, Feb 9, 2014 at 5:07 PM, Andrew Purtell wrote: > Thanks for the reminder! > > > On Thu, Feb 6, 2014 at 9:36 PM, Stack wrote: > > > When the following lads get a chance, please log on to this page [1] > > s

Re: Branch 4.0.0 is created for Phoenix on HBase0.98

Awesome job, Jeffrey! This is pretty exciting! Mujtaba - would it be feasible to setup Jenkins builds for this branch as well? Thanks, James On Mon, Feb 10, 2014 at 1:38 PM, Jeffrey Zhong wrote: > Hey, > > I created branch 4.0.0 from master branch for Phoenix on HBase0.98. The > code can work

Branch 4.0.0 is created for Phoenix on HBase0.98

Hey, I created branch 4.0.0 from master branch for Phoenix on HBase0.98. The code can work on tip of HBase0.98 & trunk branch but not HBase0.96(only need trivial changes to make it work though) because some "private" Hbase interface changes from release to release. We need a good way to remove all

Re: [VOTE] The 2nd Phoenix 2.2.3 release candidate is available for download

+1 Verified table+index works correctly after upgrading to Apache Phoenix 2.2.3 (RC1) from Github Phoenix 2.2.2 and there is no performance regression . -Mujtaba On Mon, Feb 10, 2014 at 12:03 PM, James Taylor wrote: >

Re: [VOTE] The 2nd Phoenix 2.2.3 release candidate is available for download

+1 I created a table and index on previous Github Phoenix 2.2.2, deployed the Apache Phoenix 2.2.3, verified table and index both work correctly after upgrade for both aggregate, scan, and explain plan. James On Mon, Feb 10, 2014 at 10:24 AM, Mujtaba Chohan wrote: > The 2nd Phoenix 2.2.3 RC i

[jira] [Created] (PHOENIX-33) Support table-wildcard select in join queries

Maryann Xue created PHOENIX-33: -- Summary: Support table-wildcard select in join queries Key: PHOENIX-33 URL: https://issues.apache.org/jira/browse/PHOENIX-33 Project: Phoenix Issue Type: Improve

Re: good news - we can keep our Apache Phoenix name

Agreed! Suggestions welcome as I'm terrible at stuff like that... James On Mon, Feb 10, 2014 at 10:35 AM, Mujtaba Chohan wrote: > great! ...time for a new Apache Phoenix logo. > > > On Mon, Feb 10, 2014 at 10:01 AM, Vasudevan, Ramkrishna S < > ramkrishna.s.vasude...@intel.com> wrote: > > > +1.

Re: good news - we can keep our Apache Phoenix name

great! ...time for a new Apache Phoenix logo. On Mon, Feb 10, 2014 at 10:01 AM, Vasudevan, Ramkrishna S < ramkrishna.s.vasude...@intel.com> wrote: > +1..great news... > > -Original Message- > From: James Taylor [mailto:jamestay...@apache.org] > Sent: Monday, February 10, 2014 11:27 PM >

[VOTE] The 2nd Phoenix 2.2.3 release candidate is available for download

The 2nd Phoenix 2.2.3 RC is available for download at http://people.apache.org/~mujtaba/phoenix-2.2.3RC1/ Signed with my code signing key: 17AF6E3F This is source and binary release. Unfortunately the first RC was sunk due to a test failure. Jenkins run for 2.2.3 https://builds.apache.org/job/Pho

RE: good news - we can keep our Apache Phoenix name

+1..great news... -Original Message- From: James Taylor [mailto:jamestay...@apache.org] Sent: Monday, February 10, 2014 11:27 PM To: dev@phoenix.incubator.apache.org Subject: good news - we can keep our Apache Phoenix name The Apache Brand Management team approved our name today[1], so w

good news - we can keep our Apache Phoenix name

The Apache Brand Management team approved our name today[1], so we can keep our Apache Phoenix name. We'll proceed with voting on our first release shortly. Thanks, James [1] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-44

[jira] [Commented] (PHOENIX-19) Enhance JDBC connection of Phoenix to support connecting to a Secure HBase cluster.

[ https://issues.apache.org/jira/browse/PHOENIX-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896767#comment-13896767 ] Anil Gupta commented on PHOENIX-19: --- My pleasure in contributing to Open Source. Ok, sin

[jira] [Commented] (PHOENIX-32) Replace generic ColumnModifier with specific SortOrder

[ https://issues.apache.org/jira/browse/PHOENIX-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896687#comment-13896687 ] Hudson commented on PHOENIX-32: --- FAILURE: Integrated in Apache Phoenix - Build:master #41 (S

[jira] [Updated] (PHOENIX-32) Replace generic ColumnModifier with specific SortOrder

[ https://issues.apache.org/jira/browse/PHOENIX-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Toens updated PHOENIX-32: --- Attachment: Phoenix-32.patch Patch file > Replace generic ColumnModifier with specific SortOrder > -

[jira] [Created] (PHOENIX-32) Replace generic ColumnModifier with specific SortOrder

Simon Toens created PHOENIX-32: -- Summary: Replace generic ColumnModifier with specific SortOrder Key: PHOENIX-32 URL: https://issues.apache.org/jira/browse/PHOENIX-32 Project: Phoenix Issue Type