Re: [VOTE] The first rc (RC0) for Phoenix 4.8.1 is available

My key is the KEYS file in the dev directory only. Will load into KEYS file you mention. My key's fingerprint is A1A7 5143 64FB 05BC C9A1  5A9D D0BE B8C5 C7CF E328. -- Lars From: Josh Elser To: dev@phoenix.apache.org Sent: Friday, September 23, 2016 2:48 PM Subject:

Re: [VOTE] The first rc (RC0) for Phoenix 4.8.1 is available

+1 (binding) Checked sums and signature ​s​ : ok RAT check ​ of all sources​ : ok Built ​ 0.98 and ​ ​1.2 versions ​ from source: ok (7u80) Unit tests ​of ​0.98 version​: ok (7u80) Started up an HBase minicluster (0.98.22-hadoop2), dropped in the server jar ​ from the 0.98 binary artifact​ ,

[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=15519309#comment-15519309 ] William Yang commented on PHOENIX-3328: --- The patch handles PK ranges OR operation only for the

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

Ted: The email in my 'send box' has the attachment, but the email received didn't. I don't why. I filed a jira, see https://issues.apache.org/jira/browse/PHOENIX-3328. I only add one test case for this. We already have some UT and IT for other scenarios that WHERE clause shouldn't be optimized

[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 columns >

[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: Skip scan optimization failed for multi pk columns

William, Yes, PHOENIX-1801 is a good one too. IMHO, we should do that work in the calcite branch where we can leverage the cost based optimizer framework in Calcite. Thanks, James On Sat, Sep 24, 2016 at 7:36 AM, Ted Yu wrote: > William: > I don't see attachment in your

[jira] [Commented] (PHOENIX-3326) Restoring SYSTEM.CATALOG from snapshot causes clients to run into UpgradeInProgressException

[ https://issues.apache.org/jira/browse/PHOENIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519226#comment-15519226 ] James Taylor commented on PHOENIX-3326: --- The problem with putting the lock on SYSTEM.CATALOG cell

[jira] [Commented] (PHOENIX-3326) Restoring SYSTEM.CATALOG from snapshot causes clients to run into UpgradeInProgressException

[ https://issues.apache.org/jira/browse/PHOENIX-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519183#comment-15519183 ] Lars Hofhansl commented on PHOENIX-3326: Hmm. I think if we expire the lock we can leave on

Re: Skip scan optimization failed for multi pk columns

William: I don't see attachment in your original email. Mind sharing the JIRA number once you open the JIRA (I assume the patch would be attached there) ? Thanks On Thu, Sep 22, 2016 at 9:24 PM, William wrote: > Hi all, >This is a simple scenario, there are two tables: >

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

OK James, I'll do this tomorrow and have a look at those tickets. Also, I am planning to do this, https://issues.apache.org/jira/browse/PHOENIX-1801. I'd like to support intersect and union scenario first, then sort union. Actually the QueryOptimizer doesn't 'choose' the appropriate index