[jira] [Updated] (PHOENIX-3498) Query with index failed when query back to data table with desc PK column

[ https://issues.apache.org/jira/browse/PHOENIX-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-3498: -- Attachment: PHOENIX-3498.patch > Query with index failed when query back to data table w

[jira] [Created] (PHOENIX-3498) Query with index failed when query back to data table with desc PK column

William Yang created PHOENIX-3498: - Summary: Query with index failed when query back to data table with desc PK column Key: PHOENIX-3498 URL: https://issues.apache.org/jira/browse/PHOENIX-3498

Query with index failed when data table's PK column is in DESC order

xists. Are there any similar scenarios that failed considering the sort order information? Thanks. William

Re:Re: Why index table inherits SALT_BUCKETs from data table?

Hi James, I tried, it acts exactly as what you said. Thanks very much. William. At 2016-11-02 12:54:26, "James Taylor" wrote: >Hi William, >By default, an index will have the same number of salt buckets as the data >table, but you can override that by setting SALT_BU

Why index table inherits SALT_BUCKETs from data table?

to do with the selectivity of the PK columns of data table. I think it will be better if users can decide whether to use salt buckets for index tables. Does someone have any idea of this behavior? Thanks William.

[jira] [Commented] (PHOENIX-3335) Improve documention of unsigned_long type mapping

[ https://issues.apache.org/jira/browse/PHOENIX-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528692#comment-15528692 ] William Yang commented on PHOENIX-3335: --- Build.sh failed on my MAC and I

[jira] [Updated] (PHOENIX-3335) Improve documention of unsigned_long type mapping

[ https://issues.apache.org/jira/browse/PHOENIX-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-3335: -- Attachment: PHOENIX-3335.patch > Improve documention of unsigned_long type mapp

[jira] [Comment Edited] (PHOENIX-3335) long type in hbase mapping pheonix type error

[ https://issues.apache.org/jira/browse/PHOENIX-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525803#comment-15525803 ] William Yang edited comment on PHOENIX-3335 at 9/27/16 11:1

[jira] [Commented] (PHOENIX-3335) long type in hbase mapping pheonix type error

[ https://issues.apache.org/jira/browse/PHOENIX-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525803#comment-15525803 ] William Yang commented on PHOENIX-3335: --- This is exactly how it works. see

[jira] [Commented] (PHOENIX-3328) Skip scan optimization failed for multi pk columns

[ https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15519309#comment-15519309 ] William Yang commented on PHOENIX-3328: --- The patch handles PK ranges OR opera

Re:Re: Skip scan optimization failed for multi pk columns

ouldn't be optimized to skip scan filter. i.e. EvaluationOfORIT. Please take a look at it. Thanks. William. At 2016-09-24 22:36:08, "Ted Yu" wrote: >William: >I don't see attachment in your original email. > >Mind sharing the JIRA number once you open t

[jira] [Updated] (PHOENIX-3328) Skip scan optimization failed for multi pk columns

[ https://issues.apache.org/jira/browse/PHOENIX-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-3328: -- Attachment: PHOENIX-3328.patch > Skip scan optimization failed for multi pk colu

[jira] [Created] (PHOENIX-3328) Skip scan optimization failed for multi pk columns

William Yang created PHOENIX-3328: - Summary: Skip scan optimization failed for multi pk columns Key: PHOENIX-3328 URL: https://issues.apache.org/jira/browse/PHOENIX-3328 Project: Phoenix

Re:Re: Skip scan optimization failed for multi pk columns

27; the appropriate index tables, but just generate all probable query plans then try to find the 'best'. If we want to support complete index merge algorithm, we have to introduce cost model and this is not an easy job. Do you have any suggestions? Thanks. William. At 2016-09-23 14:4

Skip scan optimization failed for multi pk columns

ExpressionVisitor#orKeySlots(), see the attached patch file for detail. The main idea is we allow slot in childSlot is null, only if all slots afterwards are null too. So the following statements are still rejected: select * from t2 where (pk1 > 10 and pk1 < 20) or (pk2 > 30 and pk2 < 40) Please review this. Thanks. William.

Re:Re: Some questions about secondary index (reformat the tables)

g such detailed questions. William. At 2016-08-19 07:54:52, "James Taylor" wrote: >Hi William, >I think those classes demonstrate how to use mutable secondary indexes >directly with HBase (i.e. outside of Phoenix). I agree, they could be moved >into the IT directory. > >You m

Re:Re: Some questions about secondary index

We don't store the include values in row key, but in values. Thanks for your patience of answering such detailed questions. William. At 2016-08-19 07:54:52, "James Taylor" wrote: >Hi William, >I think those classes demonstrate how to use mutable secondary indexes >dire

[jira] [Commented] (PHOENIX-3185) Error: ERROR 514 (42892): A duplicate column name was detected in the object definition or ALTER TABLE statement. columnName=TEST_TABLE.C1 (state=42892,code=514)

[ https://issues.apache.org/jira/browse/PHOENIX-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425796#comment-15425796 ] William Yang commented on PHOENIX-3185: --- I'm afraid we already has an is

Some questions about secondary index

complex way to generating the index update? The 'roll back' operation in NonTxIndexBuilder, and IndexUpdateManager#fixUpCurrentUpdates(), I cannot see the purpose of these facilities. I think I must have missed something very important, which might be some core concept or design. May someone provide me an easier way to understand these code? Thanks. William

Re:JDBC Connection time

ll be less than 1 ms as phoenix connection is designed to be light weight and all connections that connected to the same hbase cluster will share the same low-level hbase connection. I hope this will help you out. William. At 2016-08-03 12:11:42, "김민석" wrote: >Hello All, &

Useless Delete operations in global index update

he first region of the index table handle more than 10 times requests, as it handles all the delete requests itself if the scenario is 'append more and update less'. This wastes a lot of RPC calls and extends the RT of the data table UPSERT operation. Might anyone explain this for me? Thanks. William.

TPC-C benchmark

Hi all, I am studying how to run TPC-C benchmark on Phoenix. Has anyone ever done this before? Any suggestions? Thanks. William.

[jira] [Commented] (PHOENIX-930) duplicated columns cause query exception and drop table exception

[ https://issues.apache.org/jira/browse/PHOENIX-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15309066#comment-15309066 ] William Yang commented on PHOENIX-930: -- [~junegunn], Why not

[jira] [Commented] (PHOENIX-2936) Missing antlr runtime on server side after PHOENIX-2908

[ https://issues.apache.org/jira/browse/PHOENIX-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299268#comment-15299268 ] William Yang commented on PHOENIX-2936: --- I am really sorry for this. I di

[jira] [Commented] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293120#comment-15293120 ] William Yang commented on PHOENIX-2908: --- I think the test result is OK. I che

Re:Re: Hudson build failure for PHOENIX-2809

e build process, not the attach operation. Thanks again. William At 2016-05-20 12:30:34, "Nick Dimiduk" wrote: >Apache Jenkins login is quite restricted -- many project committers do not >have accounts. Pre-commit builds are triggered by attaching patch files to >a Jira and p

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: PHOENIX-2908_removeBothAntlr_v3.patch > phoenix-core depends on both antlr

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: (was: PHOENIX-2908_removeBothAntlr_v2.patch) > phoenix-core depends on b

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: PHOENIX-2908_removeBothAntlr_v2.patch > phoenix-core depends on both antlr

Hudson build failure for PHOENIX-2809

hoenix.apache.org/contributing.html) Thanks very much. William.

[jira] [Commented] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292504#comment-15292504 ] William Yang commented on PHOENIX-2908: --- I have updated the patch for ma

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: PHOENIX-2908_removeBothAntlr_v2.patch > phoenix-core depends on both antlr

[jira] [Commented] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292495#comment-15292495 ] William Yang commented on PHOENIX-2908: --- This patch remove dependencies for a

[jira] [Commented] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288170#comment-15288170 ] William Yang commented on PHOENIX-2908: --- Yes, the master branch doesn't

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: PHOENIX-2908_removeBothAntlr.patch There's also an option 2: remove both

[jira] [Updated] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

[ https://issues.apache.org/jira/browse/PHOENIX-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2908: -- Attachment: PHOENIX-2908_removeOnlyAntlr2.7.7.patch option 1: The safest way, only remove

[jira] [Created] (PHOENIX-2908) phoenix-core depends on both antlr 3.5 and antlr 2.7.7

William Yang created PHOENIX-2908: - Summary: phoenix-core depends on both antlr 3.5 and antlr 2.7.7 Key: PHOENIX-2908 URL: https://issues.apache.org/jira/browse/PHOENIX-2908 Project: Phoenix

Antlr dependency issue

Hi all I found a weird problem when executing 'mvn dependency:tree -pl=phoenix-core'. It shows that we depends on both antlr-3.5.jar and antlr-2.7.7.jar. [INFO] org.apache.phoenix:phoenix-core:jar:4.6-adh6u-SNAPSHOT [INFO] +- org.antlr:antlr:jar:3.5:compile [INFO] | \- org.antlr:ST4:jar:4.0

Re:Re: Re: Support HBase Increment and CheckAndMutate API

Hi James, Thanks a lot for your advice, I will give it a shot. William At 2016-05-04 23:34:19, "James Taylor" wrote: >Hi William, >Tephra is used in production for every CDAP customer[1], so it does have >production usage. If your scenario is OLTP, then transactional

Re:Re: Support HBase Increment and CheckAndMutate API

t. Above all, I cannot see other choices to do the job quickly and reliably. At 2016-05-04 14:51:59, "James Taylor" wrote: >Hi William, >I'd recommend looking at supporting these HBase features through the >standard SQL merge statement where they compile down to these nati

Support HBase Increment and CheckAndMutate API

erate List, it is hard to add a new data type to the write path. So I have to create a new write path. May someone give me some advice or solutions? Thanks. William

A detail in LimitNodeCompiler

Hi all, I have a very small question. In LimitNodeCompiler.LimitParseNodeVisitor#visit(BindParseNode), For BindParseNode, it creates a LiteralParseNode and visit it again. Why? Why not handle it directly? I don't realy understand what the comments said: // Resolve the bind value, create a Li

[jira] [Comment Edited] (PHOENIX-2520) Create DDL property for metadata update frequency

[ https://issues.apache.org/jira/browse/PHOENIX-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088634#comment-15088634 ] William Yang edited comment on PHOENIX-2520 at 1/8/16 3:2

[jira] [Commented] (PHOENIX-2520) Create DDL property for metadata update frequency

[ https://issues.apache.org/jira/browse/PHOENIX-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088634#comment-15088634 ] William Yang commented on PHOENIX-2520: --- Updating the meta data periodically

[jira] [Updated] (PHOENIX-2520) Create DDL property for metadata update frequency

[ https://issues.apache.org/jira/browse/PHOENIX-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Yang updated PHOENIX-2520: -- Attachment: preferMetaCache.patch > Create DDL property for metadata update freque

Re:Re: Re: Why do we need an empty column when doing upsert?

Hi Gabriel, Thanks a lot for your reply. I was confused. I misunderstood 'not null' constraint as 'required at each upsert'. -William At 2015-12-22 15:25:40, "Gabriel Reid" wrote: >Hi William, > >Yes, all your tests there look correct, and it look

Re:Re: Why do we need an empty column when doing upsert?

: Invalid not null constraint on non primary key column columnName=TT.B I figured out one reason : the data of a phoenix table might be written by hbase native api, which does not support not null constraint on non pk column. Is it right? Is it the primary reason? thanks - William At

<    1   2