Re: Phoenix custom UDF

Hi Akhil, You want to create an Array, convert it to its byte[] representation, and set the ptr argument to point to it. Take a look at ArrayIT for examples of creating an Array: // Create Array of FLOAT Float[] floatArr = new Float[2]; floatArr[0] = 64.87; floatArr[1] = 89.96;

Re: [ANNOUNCE] Apache Phoenix 4.8.1 is available for download

Apache Phoenix enables OLTP and operational analytics for Hadoop through SQL support using HBase as it's backing store and integrates with other projects in the ecosystem such as Spark, Hive, Pig, Flume, and MapReduce. On Tue, Sep 27, 2016 at 10:27 PM, wrote: > The Phoenix

Re: LOCAL vs TRANSACTIONAL indexes

ng inconsistent results) or does the table > write get rolled back? > > > "From the same client, there is no race condition. The upsert statement > is synchronous, so when control returns back to you, all of your data has > been written (both to the data and index table(s))

Re: can I prevent rounding of a/b when a and b are integers

Hi Noam, Please file a JIRA. As a workaround, you can do SELECT 1.0/3. Thanks, James On Wed, Sep 21, 2016 at 12:48 AM, Bulvik, Noam wrote: > Hi, > > > > When I do something like select 1/3 from the result will be > integer value (0) and not double or alike(0.33….). Is

Re: LOCAL vs TRANSACTIONAL indexes

ue, Sep 20, 2016 at 10:30 PM, Matthew Van Wely <mvanw...@salesforce.com> wrote: > Thanks James, knowing that there are no race conditions (or very > unlikely) from the same client on a mutable table is really helpful. > > Thx, > --Matt > > On Sat, Sep 17, 2016 at 4:26 PM,

Re: Full text query in Phoenix

Phoenix isn't going to help with full text search. You need to use some kind of search solution with HBase (i.e. revive HBASE-3529). Elastic Search may have something available - have you asked them? If you need to do SQL querying in addition to full text search, you could potentially use an

Re: Phoenix "LIKE 'query%' " performance

On Sunday, September 18, 2016, Cheyenne Forbes < cheyenne.osanu.for...@gmail.com> wrote: > >- Can it be fast? >- does it use the Hbase regex feature? > > It's a similar implementation, but with some optimizations around the prefix patterns mentioned below. > >- how can I make it case

Re: LOCAL vs TRANSACTIONAL indexes

On Fri, Sep 16, 2016 at 7:22 PM, Matthew Van Wely wrote: > All, > > I would like some guidance on LOCAL vs TRANSACTIONAL indexes and I > cannot quite get the details I need from the Phoenix site: > https://phoenix.apache.org/secondary_indexing.htm > > Transactional

Re: Decode rowkey

See http://search-hadoop.com/m/9UY0h2ZCvra1NlgtC1=Re+Extracting+column+values+from+Phoenix+composite+primary+key On Fri, Sep 16, 2016 at 10:46 AM, Jonathan Leech wrote: > This would be really useful. The use case I have that is similar is to map > Phoenix data to Hive (but

Re: Joins dont work

Hi Cheyenne, Are you referring to joins through the query server? Thanks, James On Thu, Sep 15, 2016 at 1:37 PM, Cheyenne Forbes < cheyenne.osanu.for...@gmail.com> wrote: > I was using phoenix 4.4 then I switched to 4.8 because I thought it was > related to version 4.4 (both on hbase 1.1.2),

Re: When would/should I use spark with phoenix?

It's not an either/or with Phoenix and Spark - often companies use both as they're very complementary. See this [1] blog for an example. Spark is a processing engine while Phoenix+HBase is a database/store. You'll need to store your data somewhere. Thanks, James [1]

Re: Specifying a cells version

See http://phoenix.apache.org/faq.html#Can_phoenix_work_on_tables_with_arbitrary_timestamp_as_flexible_as_HBase_API and http://phoenix.apache.org/rowtimestamp.html Thanks, James On Fri, Sep 9, 2016 at 3:43 PM, Paul Jones wrote: > I see that when I create a table using

Re: Cloning a table in Phoenix

Good idea - this would make a great contribution. Please file a JIRA. On Fri, Sep 9, 2016 at 6:29 AM, Kumar Palaniappan < kpalaniap...@marinsoftware.com> wrote: > Yes James. > > Kumar Palaniappan >

Re: Enabling region replication on Phoenix metadata tables

nation, distribution, copying or other > use of this communication or any attachment is strictly prohibited. If you > have received this communication in error, please notify the sender > immediately by reply e-mail and promptly destroy all electronic and printed > cop

Re: Enabling region replication on Phoenix metadata tables

Take a look at this[1] thread for a discussion on replication of system tables. You can replicate the SYSTEM.CATALOG table, but you have to be very careful. Make sure to disable and discard replicated data for SYSTEM.CATALOG while any Phoenix upgrade is in progress (i.e. first connection after

Re: Full text query in Phoenix

Hi Cheyenne, Phoenix does not have full text query capability, so the best you can do today is use our regex built-in functions (which won't be particularly performant). Would you mind filing a JIRA with any ideas for how best to expose this functionality? Thanks, James On Wednesday, September 7,

Re: Any feedback on the nascent Phoenix Tuning Guide?

you think? > > Peter > > > > Peter Conrad > > Staff Technical Writer: Infrastructure | salesforce.com > > Office: (415) 471-5265 > > > [image: http://www.salesforce.com/signature] > <http://www.salesforce.com/signature> > > -- > > > On Tue

Re: org.apache.hadoop.hbase.DoNotRetryIOException

> afther that, i can't drop my table and get the DoNotRetryIOException > > I am not sure whether this is an issue or the version latter had handled > this(my version is 4.4.0 ). > But in my opinion ,phoenix shoule not create a helf table when customer's > grammer has error

Re: Any feedback on the nascent Phoenix Tuning Guide?

Thanks for putting this together and reaching out to the user community, Peter. I suspect about half of the questions on our list are tuning/perf related. Would be great to get feedback on this guide in terms of: - Would this guide be a good starting place for users (i.e. a kind of FAQ for

Re: Tephra errors when trying to create a transactional table in Phoenix 4.8.0

Hi Francis, Is that the complete log for the transaction manager and if not would you mind attaching that to a new JIRA? Thanks, James On Wednesday, August 31, 2016, F21 wrote: > Hey Thomas, > > Where are the Transaction Manager logs located? I have a >

Re: Extracting column values from Phoenix composite primary key

Anil, Phoenix's API is JDBC, so just be aware that you're embarking on usage of unsupported and mostly undocumented APIs. Not to say they will change, but they can and might. It'll require you looking at source code, running it in a debugger, and some trial and error to use these. For walking

Re: high client cpu usage

The client typically does a merge sort when combining results from paralllel scans. Not sure if this would explain the CPU/memory usage you're seeing. Can you narrow it down to a particular query that's causing the issue? Thanks, James On Thu, Aug 25, 2016 at 6:49 AM, John Leach

Re: CsvBulkLoadTool with ~75GB file

Maybe this will help? http://phoenix.apache.org/bulk_dataload.html#Permissions_issues_when_uploading_HFiles bq. I struggle to understand how to use split points in the create statement. You can't always use split points - it depends on your schema and the knowledge you have about the data being

Re: [ANNOUNCE] Apache Phoenix 4.8.0 released

This is good feedback, Afshin. Thanks for letting us know. I've updated the download page to provide a link to the new fixes/features. Would be great if this link could be dynamic (i.e. always point to the release notes from the last released version). Anyone know how to do this? I've also

Re: UnknowScanner/ScannerTimeoutException using IndexTool MR

Hi Nathan, If the index is not completely built, then that'd definitely be a bug for it to be put in an active state. Please file a JIRA if that's the case. Is it possible that the part of the job that failed was retried and ended up being successful? Also, any chance you could use 4.8.0?

Re: Index Maintenance on Secondary Indices Marked as UNUSABLE

?focusedCommentId=15280249=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15280249 On Mon, Aug 15, 2016 at 5:12 PM, James Taylor <jamestay...@apache.org> wrote: > Hi Julian, > Yes, marking an index as UNUSABLE simply means it won't be considered at

Re: Index Maintenance on Secondary Indices Marked as UNUSABLE

Hi Julian, Yes, marking an index as UNUSABLE simply means it won't be considered at query time. It will still be maintained. If you DISABLE it, then you won't be hit with the maintenance cost, but we don't have a mechanism to partially rebuild it. See PHOENIX-2890 and the WIP patch. In theory, if

Re: Issues while Running Apache Phoenix against TPC-H data

stall it on an existing HDP > 2.4.2 cluster? > > Thanks, > Aaron > > > On Aug 15, 2016, at 11:58, James Taylor <jamestay...@apache.org> wrote: > > Hi Amit, > Couple more performance tips on top of what Mujtaba already mentioned: > - Use the latest Phoenix (4.8.0)

Re: Issues while Running Apache Phoenix against TPC-H data

Hi Amit, Couple more performance tips on top of what Mujtaba already mentioned: - Use the latest Phoenix (4.8.0). There are some great performance enhancements in here, especially around usage of DISTINCT. We've also got some new encoding schemes to reduce table sizes in our encodecolumns branch

Re: Tables can have schema name but indexes cannot

Hi Michael, SQL dictates that an index must be in the same schema as the table it's indexing. Thanks, James On Fri, Aug 12, 2016 at 8:50 AM, Michael McAllister < mmcallis...@homeaway.com> wrote: > Hi > > > > Is there any reason we can specify the schema name for a table, but not an > index. I

Re: monitoring status of CREATE INDEX operation

ool.java:378) > > > > > My CREATE INDEX was as follows: > > create index if not exists event_object_id_idx_b on trans.event ( >> object_id >> ) ASYNC UPDATE_CACHE_FREQUENCY=6; > > > > On Thu, Aug 11, 2016 at 9:40 PM, James Taylor <jamestay...@ap

Re: monitoring status of CREATE INDEX operation

Hi Nathan, If your table is large, I'd recommend creating your index asynchronously. To do that, you'd add the ASYNC keyword to the end of your CREATE INDEX call. In this case, the index will be built through Map Reduce in a more resilient manner (i.e. the client going up or down won't impact it

Re: Phoenix Ifnull

Lukáš is correct, but if the CASE WHEN variant of the same didn't work, please file a JIRA (ideally with a unit test that repros the problem). Thanks, James On Thu, Aug 11, 2016 at 12:20 AM, Lukáš Lalinský wrote: > On Thu, Aug 11, 2016 at 9:00 AM, ankit beohar

Re: phoenix 4.7.0 on EMR 5

Hi Kim, Probably best to ask the EMR folks. That's not something we have. Thanks, James On Wed, Aug 10, 2016 at 4:36 AM, Dong-iL, Kim wrote: > Hi. > I use phoenix on amazon EMR 5. > but there is no repository of version 4.7.0-HBase-1.2. > how can I build my application with

Re: Delete large data set

Make sure to set autoCommit on before issuing the DELETE. Otherwise the client needs to hold onto all the row keys of the rows being deleted. On Tuesday, August 9, 2016, Sanooj Padmakumar wrote: > Hi All, > > What will be the best way to delete huge number of rows ( around

Re: Advice on Phoenix config

Hi Tom & James, I don't have any direct experience comparing MySQL to Phoenix and it's difficult to generalize about these things as they vary greatly from use case to use case. Best to do your own perf testing with your own queries at representative data sizes. Our Pherf tool and YCSB can help

Re: Guidance to improve upsert performance

Hi Zach, Here are some things to try: - make sure you're batching your upserts by turning off auto commit. Maybe start with a batch size of 1000 and commit when you reach this. - to reduce RPC traffic, set the UPDATE_CACHE_FREQUENCY (4.7 or above) on your table and indexes when you create them (or

Re: Phoenix upsert query time

Short of upgrading to 4.7 to leverage the UPDATE_CACHE_FREQUENCY feature, you can try setting the CURRENT_SCN property to Long.MAX_VALUE when you connect. Another alternative would be to set it to one more than the creation time of your tables. You can control the timestamp your tables are created

Re: Phoenix Create table timeout

Yes, a MR option would be great. I filed PHOENIX-3125 for this. Give our MR support, this would be a good initial contribution for someone. Thanks, James On Thu, Jul 28, 2016 at 11:16 AM, Simon Wang wrote: > This isn’t a solution but I have encountered this problem

Re: How to tell when an insertion has "finished"

That's a good point, Mujtaba. Not sure which replication he meant either. On Thu, Jul 28, 2016 at 4:02 PM, Mujtaba Chohan <mujt...@apache.org> wrote: > Oh sorry I thought OP was referring to HDFS level replication. > > On Thu, Jul 28, 2016 at 3:48 PM, James Taylor <jame

Re: How to tell when an insertion has "finished"

I believe you can also measure the depth of the replication queue to know what's pending. HBase replication is asynchronous, so you're right that Phoenix would return while replication may still be occurring. On Thu, Jul 28, 2016 at 12:06 PM, Mujtaba Chohan wrote: > Query

Re: Emulating a true INSERT or UPDATE

James, Your logic looks correct, assuming that you have the complete row keys in your SELECT statement. FYI, the transaction will start automatically at (2). You can optimize this slightly by just doing a COUNT(*) instead of returning the rows back to the client. For the UPDATE case, you'd throw

Re: querying time for Apache Phoenix

On Wed, Jul 27, 2016 at 8:07 AM, Heather, James (ELS) < james.heat...@elsevier.com> wrote: > - select * from documents where profile_id = ? (multiple rows returned, > doing a full scan) --- 5 sec > > See https://phoenix.apache.org/secondary_indexing.html#Index_Usage for > when an

Re: querying time for Apache Phoenix

RPCs as would otherwise occur when a scan is executed. Thanks, James On Wed, Jul 27, 2016 at 8:12 AM, Heather, James (ELS) < james.heat...@elsevier.com> wrote: > On Tue, 2016-07-26 at 08:39 -0700, James Taylor wrote: > > - if you're querying for a single row, use the serial and s

Re: querying time for Apache Phoenix

of the week. We're going to try doing monthly point releases after that with a minor release every three months. But given that it's open source, it can be difficult to pin this down exactly. > > > Thanks, > > Irina > -- > *From:* James Taylor <james

Re: querying time for Apache Phoenix

Hi Irina, I'd recommend trying the following: - set the UPDATE_CACHE_FREQUENCY=6 property when you create your table and index to prevent extra RPCs at query time. - if you're querying for a single row, use the serial and small hints like this: /*+ SERIAL SMALL */ - though not strictly

Re: Local Phoenix installation for testing

Hi Simon, Do you mean to run the unit tests? There's no setup required. You can directly run the unit tests through maven or Eclipse. Thanks, James On Thu, Jul 21, 2016 at 2:34 PM, Simon Wang wrote: > Hi all, > > Does anyone have previous experience of setting up Phoenix

Re: Get region for row key

nd do `table.newKey(ptr, >>> pksByteArray)` >>> 5. Eventually, get salted key as `SaltingUtil.getSaltedKey(ptr, >>> table.getBucketNum())` >>> >> > Best, > Simon > > On Jul 12, 2016, at 10:03 AM, James Taylor <jamestay...@apache.org>

Re: Get region for row key

ration, and actually tried to use > it. Sadly we are running Hive 0.13-1. It doesn’t seem that we are moving to > 1.2.0+ any time soon. It would be great if there will be an 0.13-1 > compatible version. > > By the way, is there any target release date for 4.8? > > Thanks,

Re: Get region for row key

Hi Simon, I still don't understand the use case completely. Also, did you know Phoenix has Hive integration now (as of 4.8)? Would it be possible for you to try using that? My initial impression is that you're dipping down to to low of a level here, using may non public APIs which may change in

Re: Index tables at scale

cvml','mujt...@apache.org');>> wrote: > > 12 index tables * 256 region per table = ~3K regions for index tables > assuming we are talking of covered index which implies 200+ regions/region > server on a 15 node cluster. > > On Mon, Jul 11, 2016 at 1:58 PM, James Taylor <

Re: Index tables at scale

extra write time cost is okay. But the number of > regions is too high for us. > > Best, > Simon > > > On Jul 9, 2016, at 1:18 AM, James Taylor <jamestay...@apache.org> wrote: > > Hi Simon, > The reason we've taken this approach with views is that it's possible

Re: Index tables at scale

Hi Simon, The reason we've taken this approach with views is that it's possible with multi-tenancy that the number of views would grow unbounded since you might end up with a view per tenant (100K or 1M views or more - clearly too many for HBase to handle as separate tables). With secondary

Re: Errors while launching sqlline

Phoenix 4.7.0 does not support HBase 1.2.1, but Phoenix 4.8.0 will. We're very close to getting an RC up for this, so stay tuned. Thanks, James On Sun, Jul 3, 2016 at 7:36 AM, Vasanth Bhat wrote: > Hi , > >I am stuck not able to progress. Any suggestions to

Re: how to avoid full scan

Hi, One way to forbid a full table scan, is to have your own client which compiles the query first (you'd need to dip down under JDBC -- see QueryComilerTest.getQueryPlan() for an example) to get the QueryPlan. You can then easily detect if it's a full table scan looking at the ScanRanges from

Re: Bulk loading and index

Tongzhou, Please file a JIRA for supporting ALTER INDEX REBUILD ASYNC. This would be a good addition and not very difficult to implement. Contributions are, of course, always welcome. Regards, James On Sun, Jun 26, 2016 at 2:45 AM, Ankit Singhal wrote: > HI

Re: Version compatibility policy

James, We support upgrading among minor versions with no downtime (at least two versions back, but in reality we go back further than that currently). See our backward compatibility documentation here: http://phoenix.apache.org/upgrading.html. For 4.8, we've made some changes to local indexing

Re: Online schema changes

Hi James, We don't hold locks on tables during DDL operations (other than for the one operation that updates the system catalog with the new mutations). Adding a column does not require any additional data-related operations as existing rows will simply return null for the column. For deletion of

Re: Drill on Phoenix

Yes, we've created a new Phoenix storage plugin for Drill here[1], and there's a good presentation put together by Jacques on here[2] that covers Drillix (that's our initiative name) plus Drill and Arrow. This is definitely a work in progress at the POC level, but IMHO is very promising. We need a

Re: Table replication

outside of HBase. There are no JIRAs filed for this yet. > > Thanks, > Saurabh. > Sent from Bloomberg Professional for iPhone > > > - Original Message - > From: James Taylor <user@phoenix.apache.org> > To: user@phoenix.apache.org > At: 09-Jun-2016 11:42:46 >

Re: Coalesce function returns nulls?

Thanks for bringing this to our attention, Marek. I took a look and found an issue with the coalesce function. I filed PHOENIX-2994 with a patch there. Please let us know if it fixes the issue you're seeing (and if not, then please get us a unit test). James On Mon, Jun 13, 2016 at 2:02 PM,

Re: [ANNOUNCE] Phoenix 4.7 now supported in Amazon EMR

They actually approached us, so no persuasion necessary! On Thu, Jun 9, 2016 at 11:05 PM, Heather, James (ELS) < james.heat...@elsevier.com> wrote: > That's really excellent news! Well done for persuading them! > > James > > On 10 Jun 2016, at 00:16, James Taylor <james

[ANNOUNCE] Phoenix 4.7 now supported in Amazon EMR

Thanks to some great work over at Amazon, there's now support for Phoenix 4.7 on top of HBase 1.2 in Amazon EMR. Check it out and give it a spin. Detailed step-by-step instructions available here: http://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/emr-phoenix.html Thanks, James

Re: Table replication

Hi JM, Are you looking toward replication to support DR? If so, you can rely on HBase-level replication with a few gotchas and some operational hurdles: - When upgrading Phoenix versions, upgrade the server-side first for both the primary and secondary cluster. You can do a rolling upgrade and

Re: create schema on write

e dynamic > columns. Could you elaborate? Thanks! > > On Fri, Jun 3, 2016 at 10:36 AM, James Taylor <jamestay...@apache.org> > wrote: > >> That's pretty slick, Steve. Another variant along the same lines would be >> to create/alter a view over a base table where you use

Re:

hy do you not want to do so? >> >> On Thu, Jun 2, 2016 at 7:11 PM, Rahul Jain <rja...@gmail.com >> <javascript:_e(%7B%7D,'cvml','rja...@gmail.com');>> wrote: >> >>> >>> Folks, >>> >>> I used this question earlier on the wrong list; posting

Re: Exception when create an index with UDF but not using this UDF in select statement

Very helpful analysis, Mac. Please file a JIRA. It seems that you've found an issue with functional indexes over UDFs. Thanks, James On Wednesday, June 1, 2016, 方震(大数据&滴滴研究院) wrote: > Guys, > > One exception i have met but not sure if it is an issue. here are the steps

Re: Secondary index rebuilding

Yes, see https://phoenix.apache.org/secondary_indexing.html#Consistency_ Guarantees On Wednesday, June 1, 2016, Sumit Nigam wrote: > Hi, > > I recently noticed that one of my secondary index was short of 2 entries > compared to data table. > > AFAIK, the first update is

[ANNOUNCE] PhoenixCon the day after HBaseCon

The inaugural PhoenixCon will take place 9am-1pm on Wed, May 25th (at Salesforce @ 1 Market St, SF), the day after HBaseCon. We'll have two tracks: one for Apache Phoenix use cases and one for Apache Phoenix internals. To RSVP and for more details see here[1]. We hope you can make it! James

Re: Golang driver for Phoenix and Avatica available

Awesome, Francis! Thanks so much. James On Mon, May 16, 2016 at 10:44 PM, F21 wrote: > Hi all, > > I have just open sourced a golang driver for Phoenix and Avatica. > > The code is licensed using the Apache 2 License and is available here: >

Re: Phoenix on HBase - Adding data to HBase reflects on Phoenix table?

Hello Emanuele, Take a look at these FAQs and hopefully they answer your questions. You can create a VIEW instead of a TABLE and there's no need to add the empty key value (though you cannot use Phoenix APIs to change the table, only read from it):

Re: smarter using of index while querying?

Please read the following and hopefully it will answer your questions: https://phoenix.apache.org/secondary_indexing.html#Index_Usage On Mon, May 9, 2016 at 11:36 PM, 金砖 wrote: > hi, I'm using phoenix-4.7, and I found phoenix did not use index > efficiently enough. > Can

Re: Write path blocked by MetaDataEndpoint acquiring region lock

On Mon, May 9, 2016 at 9:52 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > On Mon, May 9, 2016 at 12:06 AM, James Taylor <jamestay...@apache.org> > wrote: > >> Have you tried using the UPDATE_CACHE_FREQUENCY property [1] I mentioned >> before? >> &

Re: How to troubleshoot 'Could not find hash cache for joinId' which is failing always for some users and never for others

It's quite possible you're hitting a bug that has been fixed as you're 5 or 6 releases behind on Phoenix and 14 patch releases behind on HBase. Thanks, James On Thu, May 5, 2016 at 8:14 AM, Kathiresan S wrote: > We had a similar problem while using explicit JOIN

Re: How to carry out data migration?

You can also use our MR integration to write to a different cluster than you're reading from (see PHOENIX-1653). Thanks, James On Wednesday, May 4, 2016, 景涛 <844300...@qq.com> wrote: > > Thank you very much Sandeep ; > > -- 原始邮件 -- > *发件人:* "Sandeep

Re: Various performance questions

In 4.7+, take a look at the UPDATE_CACHE_FREQUENCY property for reducing the RPC calls made for the SYSTEM.CATALOG: https://phoenix.apache.org/#Altering James On Thu, Apr 28, 2016 at 10:30 PM, Lukáš Lalinský wrote: > On Fri, Apr 29, 2016 at 2:58 AM, Vladimir Rodionov

Re: Load HFiles in Apache Phoenix

Hi Abel, Yes, you need to either include the empty key value or you need to declare your table as a view instead of a table (in which case it'd be read-only). Thanks, James On Wed, Apr 27, 2016 at 12:17 PM, Abel Fernández wrote: > Hi, > > I am trying to load files in

[ANNOUNCE] PhoenixCon 2016 on Wed, May 25th 9am-1pm

We invite you to attend the inaugural PhoenixCon on Wed, May 25th 9am-1pm (the day after HBaseCon) hosted by Salesforce.com in San Francisco. There will be two tracks: one for use cases and one for internals. Drop me a note if you're interested in giving a talk. To RSVP and for more details, see

Re: Undefined column. columnName=IS_ROW_TIMESTAMP

gt;>>>>>>>>> \x00\x00TEST_TABLE_2 column=0:NULLABLE, timestamp=1460354090655, >>>>>>>>>>> value=\x80\x00\x00\x00 >>>>>>>>>>> >>>>>>>>>>> _0_1460354090089\x00CDS_PK >>>>>>>&

Re: Apache Phoenix + Wildfly (JEE)

Are you aware of the work being done to create shaded jars (PHOENIX-2535)? This would be a good driver for that effort. Thanks, James On Thu, Apr 21, 2016 at 8:43 AM, wrote: > > It would be great if I could get some feedback on my current integration > effort of

Re: Rebuilding phoenix index

Hi Michal, As a workaround for the issue you're encountering, can dropping the index and then issuing your create index DDL statement over again? If you have a minute to file a JIRA on this, that'd be much appreciated. Thanks, James On Wed, Apr 20, 2016 at 5:45 PM, Michal Medvecky

Re: Undefined column. columnName=IS_ROW_TIMESTAMP

Arun, Please run the command Ankit mentioned in an HBase shell and post the output back here. Thanks, James On Wednesday, April 20, 2016, Arun Kumaran Sabtharishi wrote: > !describe SYSTEM.CATALOG is not returning IS_ROW_TIMESTAMP column. > > But we do see this column from

Re: Phoenix Bulk Load With Column Overrides

Note that it's case sensitive, so try upper casing your column names in your psql.py call. On Wednesday, April 20, 2016, Amit Shah wrote: > Hello, > > I am using phoenix 4.6 and trying to bulk load data into a table from a > csv file using the psql.py utility. How do I map

Re: SYSTEM.CATALOG Table Is Not Recreated

s table does not > exist. > > On Tue, Apr 19, 2016 at 12:28 PM, James Taylor <jamestay...@apache.org > <javascript:_e(%7B%7D,'cvml','jamestay...@apache.org');>> wrote: > >> Make sure you bounce your cluster too (or at a minimun the region server >> hosting the SY

Re: Query by region splits

ure how such > Phoenix query can be constructed. > > Hope this clarifies the question. > > Thanks, > Li > > On Mon, Apr 18, 2016 at 2:09 PM, James Taylor <jamestay...@apache.org> > wrote: > >> Phoenix already does this (and to a finer, configurable granularity). S

Re: Query by region splits

Phoenix already does this (and to a finer, configurable granularity). See https://phoenix.apache.org/update_statistics.html Thanks, James On Mon, Apr 18, 2016 at 2:08 PM, Li Gao wrote: > Hi, > > In Phoenix is it possible to query the data by region splits? i.e. if >

Re: Map the hbase column qualifier which is in byte type to phoenix table view

It is not currently possible to use a \0 byte value in column names (i.e. for the cq), but please feel free to file a JIRA. On Saturday, April 16, 2016, Viswanathan J wrote: > Please help on this. > On Apr 15, 2016 11:47 PM, "Viswanathan J"

Re: Phoenix for CDH5 compatibility

There's also the branch that Andrew setup here: https://github.com/chiastic-security/phoenix-for-cloudera On Saturday, April 16, 2016, rafa wrote: > Hi Swapna, > > You can download the official parcel from Cloudera, although it is not > the last phoenix version. > >

Re: Secondary indexes on dynamic columns

No, it's currently not possible to have a secondary index on dynamic columns. You can, however, create a view with new, ad hoc columns and add a secondary index on the view. On Thu, Apr 14, 2016 at 2:38 PM, wrote: > Hi, > > > > Is there a way to make phoenix

Re: Column Cardinality and Stats table as an "interface"

ding Cubes off of denormalized >>> event tables in Phoenix, or supporting BlinkDB approximation queries could >>> both be facilitated by the stats table. >>> >>> -n >>> >>> On Thu, Apr 14, 2016 at 12:24 PM, James Taylor <jamestay...@apache.

Re: Column Cardinality and Stats table as an "interface"

stable internal API? For > instance, integration with Kylin for building Cubes off of denormalized > event tables in Phoenix, or supporting BlinkDB approximation queries could > both be facilitated by the stats table. > > -n > > On Thu, Apr 14, 2016 at 12:24 PM, James Taylor <ja

Re: Column Cardinality and Stats table as an "interface"

FYI, Lars H. is looking at PHOENIX-258 for improving performance of DISTINCT. We don't yet keep any cardinality info in our stats (see PHOENIX-1178). Thanks, James On Thu, Apr 14, 2016 at 11:22 AM, Nick Dimiduk wrote: > Hello, > > I'm curious if there are any tricks for

Re: Flashback queries support in select statement

Hi Kannan, The only mechanism available is the one you mentioned: https://phoenix.apache.org/faq.html#Can_phoenix_work_on_tables_with_arbitrary_timestamp_as_flexible_as_HBase_API FWIW, opening a new connection is only creating a few Java objects, so there's no real overhead in just opening a new

Re: Speeding Up Group By Queries

at will help you benchmark your queries >> under representative data sizes? > > > I will look at the tool. > > Thanks again for sharing your inputs. > > On Mon, Apr 11, 2016 at 9:29 PM, James Taylor <jamestay...@apache.org > <javascript:_e(%7B%7D,'cvml','jamestay...@apa

Re: SQL editor for Phoenix 4.4

That's good to hear, Randy, about Zeppelin. Thanks for letting us know. Do you think it'd make sense to bundle Zeppelin in our binary distro? What's the user experience like? James On Tuesday, April 12, 2016, Randy Gelhausen wrote: > You can also use Apache Zeppelin. > >

Re: Speeding Up Group By Queries

follow what action caused this region split or was >>>>>> it >>>>>> automatically done by hbase (load balancer??) >>>>>> >>>>>> 3. Do you see lots of disk I/O on region servers during aggregation? >>>>

Re: Error while attempting join query

line.py localhost, it just freezes and doesnt proceed. Can >>>> someone please help ? >>>> >>>> >>>> #!/bin/sh >>>> mkdir /home/hadoop/phoenix/ >>>> wget >>>> >>>> htt

Re: Error while attempting join query

Support for the 2.x line was dropped over a year ago. I'd recommend encouraging the EMR folks to upgrade to the latest version of Phoenix and HBase. On Tuesday, April 5, 2016, Deepak Gopalakrishnan wrote: > Hello, > > I'm trying to join two tables that I created using Phoenix.

Re: Help with dates

Phoenix let's you cast a BIGINT directly to a DATE, like this: CAST(1458132989477 as DATE) or like this if your BIGINT is in a column value: CAST(my_bigint as DATE) Thanks, James On Tue, Apr 5, 2016 at 6:31 AM, Riesland, Zack wrote: > I have ms-based, GMT

Re: Cannot get more than 5 columns in result set

Or use a different client, like SQuirrel. On Monday, April 4, 2016, Ian Maloney wrote: > That solved it, thanks a bunch! > > On Monday, April 4, 2016, Jonathan Leech > wrote: > >> !set

<    1   2   3   4   5   6   7   >