[jira] [Commented] (PHOENIX-4321) Replace deprecated HBaseAdmin with Admin
[ https://issues.apache.org/jira/browse/PHOENIX-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253006#comment-16253006 ] Sergey Soldatov commented on PHOENIX-4321: -- Committed to 5.x-HBase-2.0 branch. > Replace deprecated HBaseAdmin with Admin > > > Key: PHOENIX-4321 > URL: https://issues.apache.org/jira/browse/PHOENIX-4321 > Project: Phoenix > Issue Type: Sub-task >Reporter: Sergey Soldatov >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 4.14.0 > > Attachments: PHOENIX-4321.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4368) Fix MapReduce related classes
[ https://issues.apache.org/jira/browse/PHOENIX-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal reassigned PHOENIX-4368: -- Assignee: Ankit Singhal > Fix MapReduce related classes > - > > Key: PHOENIX-4368 > URL: https://issues.apache.org/jira/browse/PHOENIX-4368 > Project: Phoenix > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Ankit Singhal > Fix For: 5.0.0 > > > A list of what I'm seeing failing right now: > * PhoenixIndexPartialBuildMapper.java > * MultiHfileOutputFormat.java > * FormatToKeyValueReducer.java > * PhoenixMRJobCallable.java > * PhoenixInputFormat.java > * IndexTool.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4377) Port PHOENIX-3081 to HBase-2.0
[ https://issues.apache.org/jira/browse/PHOENIX-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4377: --- Attachment: PHOENIX-4377_v1.patch > Port PHOENIX-3081 to HBase-2.0 > -- > > Key: PHOENIX-4377 > URL: https://issues.apache.org/jira/browse/PHOENIX-4377 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 5.0.0 > > Attachments: PHOENIX-4377.patch, PHOENIX-4377_v1.patch > > > -- RegionServerService is not exposed by RegionCoprocessorEnvironment now. > -- Need to update the Mock tests accordingly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (PHOENIX-4377) Port PHOENIX-3081 to HBase-2.0
[ https://issues.apache.org/jira/browse/PHOENIX-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal resolved PHOENIX-4377. Resolution: Fixed Fix Version/s: 5.0.0 > Port PHOENIX-3081 to HBase-2.0 > -- > > Key: PHOENIX-4377 > URL: https://issues.apache.org/jira/browse/PHOENIX-4377 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 5.0.0 > > Attachments: PHOENIX-4377.patch, PHOENIX-4377_v1.patch > > > -- RegionServerService is not exposed by RegionCoprocessorEnvironment now. > -- Need to update the Mock tests accordingly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4376) Fix all compilation error for package org.apache.phoenix.schema.stats and org.apache.phoenix.coprocessor
[
https://issues.apache.org/jira/browse/PHOENIX-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252990#comment-16252990
]
Ankit Singhal commented on PHOENIX-4376:
bq. We should get rid of the ((HStore) store).getScanInfo(). Can you switch
ScanInfoUtil.isKeepDeleteCells to take a Store and have the method use
store.getColumnFamilyDescriptor().getKeepDeletedCells() instead?
Actually, this whole code needs to be removed and some alternative needs to
think for PHOENIX-4378.
Committed to 5.x-HBase-2.0 branch.
> Fix all compilation error for package org.apache.phoenix.schema.stats and
> org.apache.phoenix.coprocessor
>
>
> Key: PHOENIX-4376
> URL: https://issues.apache.org/jira/browse/PHOENIX-4376
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: HBase-2.0
> Fix For: 5.0.0
>
> Attachments: PHOENIX-4376.patch
>
>
> -- It includes updating the coprocessor hook with right definition.
> -- Changing HRegionInfo to RegionInfo.
> -- Cell related changes.
> Like
> {code}
> -byte[] viewConstant = viewConstantKv == null ? null :
> viewConstantKv.getValue();
> +byte[] viewConstant = viewConstantKv == null ? null :
> CellUtil.cloneValue(viewConstantKv);
> -Cell viewStatementCell = new KeyValue(cell.getRow(),
> cell.getFamily(), VIEW_STATEMENT_BYTES,
> +Cell viewStatementCell = new
> KeyValue(CellUtil.cloneRow(cell), CellUtil.cloneFamily(cell),
> VIEW_STATEMENT_BYTES,
> {code}
> -- Update scan
> {code}
> -scan.setStartRow(HConstants.EMPTY_START_ROW);
> -scan.setStopRow(HConstants.EMPTY_END_ROW);
> +scan.withStartRow(HConstants.EMPTY_START_ROW);
> +scan.withStopRow(HConstants.EMPTY_END_ROW);
> {code}
> -- preSplit hook needs to be removed and fixed in PHOENIX-4352.
> -- Requires a separate fix of PHOENIX-4277 and PHOENIX-3081 for HBase 2.0
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (PHOENIX-4376) Fix all compilation error for package org.apache.phoenix.schema.stats and org.apache.phoenix.coprocessor
[
https://issues.apache.org/jira/browse/PHOENIX-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal resolved PHOENIX-4376.
Resolution: Fixed
> Fix all compilation error for package org.apache.phoenix.schema.stats and
> org.apache.phoenix.coprocessor
>
>
> Key: PHOENIX-4376
> URL: https://issues.apache.org/jira/browse/PHOENIX-4376
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: HBase-2.0
> Fix For: 5.0.0
>
> Attachments: PHOENIX-4376.patch
>
>
> -- It includes updating the coprocessor hook with right definition.
> -- Changing HRegionInfo to RegionInfo.
> -- Cell related changes.
> Like
> {code}
> -byte[] viewConstant = viewConstantKv == null ? null :
> viewConstantKv.getValue();
> +byte[] viewConstant = viewConstantKv == null ? null :
> CellUtil.cloneValue(viewConstantKv);
> -Cell viewStatementCell = new KeyValue(cell.getRow(),
> cell.getFamily(), VIEW_STATEMENT_BYTES,
> +Cell viewStatementCell = new
> KeyValue(CellUtil.cloneRow(cell), CellUtil.cloneFamily(cell),
> VIEW_STATEMENT_BYTES,
> {code}
> -- Update scan
> {code}
> -scan.setStartRow(HConstants.EMPTY_START_ROW);
> -scan.setStopRow(HConstants.EMPTY_END_ROW);
> +scan.withStartRow(HConstants.EMPTY_START_ROW);
> +scan.withStopRow(HConstants.EMPTY_END_ROW);
> {code}
> -- preSplit hook needs to be removed and fixed in PHOENIX-4352.
> -- Requires a separate fix of PHOENIX-4277 and PHOENIX-3081 for HBase 2.0
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4374) Flakyness with Phoenix 4.13.0 and HBase 1.3.1: RuntimeException: org.apache.phoenix.exception.PhoenixIOException: org.apache.hadoop.hbase.NamespaceNotFoundException:
[
https://issues.apache.org/jira/browse/PHOENIX-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252951#comment-16252951
]
Francis Chuang commented on PHOENIX-4374:
-
DROP SCHEMA is called once at the end of each test. However, before running
each test a CREATE SCHEMA is also called.
> Flakyness with Phoenix 4.13.0 and HBase 1.3.1: RuntimeException:
> org.apache.phoenix.exception.PhoenixIOException:
> org.apache.hadoop.hbase.NamespaceNotFoundException:
> --
>
> Key: PHOENIX-4374
> URL: https://issues.apache.org/jira/browse/PHOENIX-4374
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: Francis Chuang
> Attachments: hbase--master-m9edd51-phoenix.m9edd51.log,
> root-queryserver.log, tephra-service--m9edd51-phoenix.m9edd51.log
>
>
> I am using the Phoenix Query Server via my [Go Avatica SQL
> driver|https://github.com/Boostport/avatica].
> In terms of my set up I am running Phoenix 4.13.0 and HBase 1.3.1 in docker
> with a single node HBase using local storage. The dockerfile is available
> here: https://github.com/Boostport/hbase-phoenix-all-in-one
> Today, I updated one of my projects to use the latest version of the above
> image (Phoenix 4.13.0 and HBase 1.3.1) and my integration tests against
> Phoenix + HBase have become extremely flaky. The tests use a mix of
> transactional and non-transactional tables.
> The flakyness is that random tests will fail with the same error. If I rerun
> the tests, they sometimes pass and sometimes fail, and it is not clear why
> this is happening.
> In all of these tests, I am doing the following:
> 1. Create the schema.
> 2. Create tables.
> 3. Insert, delete and read data.
> 4. Delete the tables and schema.
> This is the error I get when trying to drop the schema:
> {code:java}
> An error was encountered while processing your request: RuntimeException:
> org.apache.phoenix.exception.PhoenixIOException:
> org.apache.hadoop.hbase.NamespaceNotFoundException: INITTEST
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
> at
> org.apache.hadoop.hbase.util.ForeignExceptionUtil.toIOException(ForeignExceptionUtil.java:45)
> at
> org.apache.hadoop.hbase.procedure2.RemoteProcedureException.fromProto(RemoteProcedureException.java:114)
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait.waitForProcedureToComplete(ProcedureSyncWait.java:85)
> at
> org.apache.hadoop.hbase.master.HMaster$15.run(HMaster.java:2717)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:133)
> at
> org.apache.hadoop.hbase.master.HMaster.deleteNamespace(HMaster.java:2705)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.deleteNamespace(MasterRpcServices.java:496)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:58601)
> at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2339)
> at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:123)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hbase.NamespaceNotFoundException):
> INITTEST
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.prepareDelete(DeleteNamespaceProcedure.java:243)
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.executeFromState(DeleteNamespaceProcedure.java:83)
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.executeFromState(DeleteNamespaceProcedure.java:49)
>
[jira] [Commented] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views and not for indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252948#comment-16252948 ] Hudson commented on PHOENIX-4379: - FAILURE: Integrated in Jenkins build Phoenix-master #1874 (See [https://builds.apache.org/job/Phoenix-master/1874/]) PHOENIX-4379 Upgrade code to create CHILD links should only create the (tdsilva: rev 2053905683409225ffdc1c0ae4fc6c759604a80d) * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/UpgradeIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java > Upgrade code to create CHILD links should only create the links for views and > not for indexes > - > > Key: PHOENIX-4379 > URL: https://issues.apache.org/jira/browse/PHOENIX-4379 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.13.1 > > Attachments: PHOENIX-4279.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4374) Flakyness with Phoenix 4.13.0 and HBase 1.3.1: RuntimeException: org.apache.phoenix.exception.PhoenixIOException: org.apache.hadoop.hbase.NamespaceNotFoundException:
[
https://issues.apache.org/jira/browse/PHOENIX-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252915#comment-16252915
]
Thomas D'Silva commented on PHOENIX-4374:
-
Are you calling DROP SCHEMA INITTEST more than once?
> Flakyness with Phoenix 4.13.0 and HBase 1.3.1: RuntimeException:
> org.apache.phoenix.exception.PhoenixIOException:
> org.apache.hadoop.hbase.NamespaceNotFoundException:
> --
>
> Key: PHOENIX-4374
> URL: https://issues.apache.org/jira/browse/PHOENIX-4374
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: Francis Chuang
> Attachments: hbase--master-m9edd51-phoenix.m9edd51.log,
> root-queryserver.log, tephra-service--m9edd51-phoenix.m9edd51.log
>
>
> I am using the Phoenix Query Server via my [Go Avatica SQL
> driver|https://github.com/Boostport/avatica].
> In terms of my set up I am running Phoenix 4.13.0 and HBase 1.3.1 in docker
> with a single node HBase using local storage. The dockerfile is available
> here: https://github.com/Boostport/hbase-phoenix-all-in-one
> Today, I updated one of my projects to use the latest version of the above
> image (Phoenix 4.13.0 and HBase 1.3.1) and my integration tests against
> Phoenix + HBase have become extremely flaky. The tests use a mix of
> transactional and non-transactional tables.
> The flakyness is that random tests will fail with the same error. If I rerun
> the tests, they sometimes pass and sometimes fail, and it is not clear why
> this is happening.
> In all of these tests, I am doing the following:
> 1. Create the schema.
> 2. Create tables.
> 3. Insert, delete and read data.
> 4. Delete the tables and schema.
> This is the error I get when trying to drop the schema:
> {code:java}
> An error was encountered while processing your request: RuntimeException:
> org.apache.phoenix.exception.PhoenixIOException:
> org.apache.hadoop.hbase.NamespaceNotFoundException: INITTEST
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
> at
> org.apache.hadoop.hbase.util.ForeignExceptionUtil.toIOException(ForeignExceptionUtil.java:45)
> at
> org.apache.hadoop.hbase.procedure2.RemoteProcedureException.fromProto(RemoteProcedureException.java:114)
> at
> org.apache.hadoop.hbase.master.procedure.ProcedureSyncWait.waitForProcedureToComplete(ProcedureSyncWait.java:85)
> at
> org.apache.hadoop.hbase.master.HMaster$15.run(HMaster.java:2717)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:133)
> at
> org.apache.hadoop.hbase.master.HMaster.deleteNamespace(HMaster.java:2705)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.deleteNamespace(MasterRpcServices.java:496)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:58601)
> at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2339)
> at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:123)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hbase.NamespaceNotFoundException):
> INITTEST
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.prepareDelete(DeleteNamespaceProcedure.java:243)
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.executeFromState(DeleteNamespaceProcedure.java:83)
> at
> org.apache.hadoop.hbase.master.procedure.DeleteNamespaceProcedure.executeFromState(DeleteNamespaceProcedure.java:49)
> at
>
[jira] [Assigned] (PHOENIX-4380) Add upgrade code to remove child links to index tables that were created incorrectly in 4.11
[ https://issues.apache.org/jira/browse/PHOENIX-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva reassigned PHOENIX-4380: --- Assignee: Thomas D'Silva > Add upgrade code to remove child links to index tables that were created > incorrectly in 4.11 > > > Key: PHOENIX-4380 > URL: https://issues.apache.org/jira/browse/PHOENIX-4380 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.14.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views and not for indexes
[
https://issues.apache.org/jira/browse/PHOENIX-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252846#comment-16252846
]
Hadoop QA commented on PHOENIX-4379:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12897641/PHOENIX-4279.patch
against master branch at commit b2d5b4d75d4698981b291fecfac3efa3fb6e2649.
ATTACHMENT ID: 12897641
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1627//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1627//console
This message is automatically generated.
> Upgrade code to create CHILD links should only create the links for views and
> not for indexes
> -
>
> Key: PHOENIX-4379
> URL: https://issues.apache.org/jira/browse/PHOENIX-4379
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.11.0
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
> Fix For: 4.13.1
>
> Attachments: PHOENIX-4279.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4372) Distribution of Apache Phoenix 4.11 for CDH 5.11.2
[ https://issues.apache.org/jira/browse/PHOENIX-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252847#comment-16252847 ] James Taylor commented on PHOENIX-4372: --- There are only about 30 commits from 4.12 to 4.13. You should be able to just cherry pick the missing ones from master over to 4.x-HBase-1.2 branch to catch it up to 4.13. I suspect they'd all apply cleanly. There are many, many stabilization fixes in 4.12 that would be critical to get into any CDH-based release IMHO. > Distribution of Apache Phoenix 4.11 for CDH 5.11.2 > -- > > Key: PHOENIX-4372 > URL: https://issues.apache.org/jira/browse/PHOENIX-4372 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.11.0 >Reporter: Pedro Boado >Priority: Minor > Labels: cdh > Attachments: PHOENIX-4372.patch > > > Changes required on top of branch 4.11-HBase-1.2 for creating a parcel of > Apache Phoenix 4.11.2 for CDH 5.11.2 . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252831#comment-16252831
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015329
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientAggregatePlan.java
---
@@ -87,6 +89,25 @@ public ClientAggregatePlan(StatementContext context,
FilterableStatement stateme
}
@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 1;
--- End diff --
So parallelLevel is 1 because aggregation is done client-side instead of
pushed to the cluster, right? Would be good to doc the thinking behind
calculating the cost throughout.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151013728
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
--- End diff --
I think we need more tests for this.
---
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015089
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
--- End diff --
What does parallelLevel represent? Is that the level of parallelization
done on the client? Is that derivable from thread pool size or cluster size?
For now, maybe have a constant and doc it a bit.
---
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252828#comment-16252828
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015944
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/optimize/QueryOptimizer.java ---
@@ -91,8 +91,23 @@ public QueryPlan optimize(PhoenixStatement statement,
SelectStatement select, Co
}
public QueryPlan optimize(QueryPlan dataPlan, PhoenixStatement
statement, List targetColumns, ParallelIteratorFactory
parallelIteratorFactory) throws SQLException {
-Listplans = getApplicablePlans(dataPlan, statement,
targetColumns, parallelIteratorFactory, true);
-return plans.get(0);
+List plans = getApplicablePlans(dataPlan, statement,
targetColumns, parallelIteratorFactory, false);
--- End diff --
We'll need to have a new master boolean config option (like
phoenix.optimize.costBased in QueryServices) that controls whether or not we're
doing cost based optimization to make sure users can disable if they want to
keep the existing behavior the same.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252832#comment-16252832
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151016226
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 10;
--- End diff --
How about passing in groupBy instead of just groupBy.isUngroupedAggregate()
as I think we'd want to get more info eventually out of the groupBy (for
example, if it's ordered or unordered which impacts memory usage
substantially)? This might help keep the interfaces a little more stable.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252823#comment-16252823
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014001
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/BaseQueryPlan.java ---
@@ -500,7 +500,10 @@ public ExplainPlan getExplainPlan() throws
SQLException {
if (context.getScanRanges() == ScanRanges.NOTHING) {
return new ExplainPlan(Collections.singletonList("DEGENERATE
SCAN OVER " + getTableRef().getTable().getName().getString()));
}
-
+
+// Initialize dummy iterator to get the stats.
--- End diff --
Comment that you need the stats prior to optimization as they help drive
cost based decisions.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014919
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 10;
--- End diff --
How about passing in groupBy instead of just groupBy.isUngroupedAggregate()
as I think we'd want to get more info eventually out of the groupBy (for
example, if it's ordered or unordered which impacts memory usage substantially)?
---
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252830#comment-16252830
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014126
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/HashJoinPlan.java ---
@@ -290,6 +291,25 @@ public FilterableStatement getStatement() {
return statement;
}
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+Cost cost = new Cost(0, 0, byteCount);
+Cost lhsCost = delegate.getCost();
+if (keyRangeExpressions != null) {
+lhsCost = lhsCost.multiplyBy(0.01);
--- End diff --
Why the 0.01? More comments would be good.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252826#comment-16252826
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015089
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
--- End diff --
What does parallelLevel represent? Is that the level of parallelization
done on the client? Is that derivable from thread pool size or cluster size?
For now, maybe have a constant and doc it a bit.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252827#comment-16252827
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151013728
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
--- End diff --
I think we need more tests for this.
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151016226
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 10;
--- End diff --
How about passing in groupBy instead of just groupBy.isUngroupedAggregate()
as I think we'd want to get more info eventually out of the groupBy (for
example, if it's ordered or unordered which impacts memory usage
substantially)? This might help keep the interfaces a little more stable.
---
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252825#comment-16252825
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151012514
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
+
+@Test
+public void testBug4288() throws Exception {
+Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
+Connection conn = DriverManager.getConnection(getUrl(), props);
+conn.setAutoCommit(true);
+try {
+conn.createStatement().execute("CREATE TABLE test4288 (\n" +
+"rowkey VARCHAR PRIMARY KEY,\n" +
+"c1 VARCHAR,\n" +
+"c2 VARCHAR)");
+conn.createStatement().execute("CREATE LOCAL INDEX
test4388_c1_idx ON test4288 (c1)");
+
--- End diff --
How about getting the explain plan here and verify that it's doing a full
table scan (i.e. before there are any stats available)?
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015944
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/optimize/QueryOptimizer.java ---
@@ -91,8 +91,23 @@ public QueryPlan optimize(PhoenixStatement statement,
SelectStatement select, Co
}
public QueryPlan optimize(QueryPlan dataPlan, PhoenixStatement
statement, List targetColumns, ParallelIteratorFactory
parallelIteratorFactory) throws SQLException {
-Listplans = getApplicablePlans(dataPlan, statement,
targetColumns, parallelIteratorFactory, true);
-return plans.get(0);
+List plans = getApplicablePlans(dataPlan, statement,
targetColumns, parallelIteratorFactory, false);
--- End diff --
We'll need to have a new master boolean config option (like
phoenix.optimize.costBased in QueryServices) that controls whether or not we're
doing cost based optimization to make sure users can disable if they want to
keep the existing behavior the same.
---
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252829#comment-16252829
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014919
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/AggregatePlan.java ---
@@ -112,7 +114,26 @@ private AggregatePlan(StatementContext context,
FilterableStatement statement, T
public Expression getHaving() {
return having;
}
-
+
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 10;
--- End diff --
How about passing in groupBy instead of just groupBy.isUngroupedAggregate()
as I think we'd want to get more info eventually out of the groupBy (for
example, if it's ordered or unordered which impacts memory usage substantially)?
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151015329
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientAggregatePlan.java
---
@@ -87,6 +89,25 @@ public ClientAggregatePlan(StatementContext context,
FilterableStatement stateme
}
@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+int parallelLevel = 1;
--- End diff --
So parallelLevel is 1 because aggregation is done client-side instead of
pushed to the cluster, right? Would be good to doc the thinking behind
calculating the cost throughout.
---
[jira] [Commented] (PHOENIX-4288) Indexes not used when ordering by primary key
[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252824#comment-16252824
]
ASF GitHub Bot commented on PHOENIX-4288:
-
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151012292
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
+
+@Test
+public void testBug4288() throws Exception {
+Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
+Connection conn = DriverManager.getConnection(getUrl(), props);
+conn.setAutoCommit(true);
+try {
+conn.createStatement().execute("CREATE TABLE test4288 (\n" +
--- End diff --
Make sure to generate a unique name for your table (see other tests for
examples)
> Indexes not used when ordering by primary key
> -
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Marcin Januszkiewicz
>Assignee: Maryann Xue
> Labels: CostBasedOptimization
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151012514
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
+
+@Test
+public void testBug4288() throws Exception {
+Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
+Connection conn = DriverManager.getConnection(getUrl(), props);
+conn.setAutoCommit(true);
+try {
+conn.createStatement().execute("CREATE TABLE test4288 (\n" +
+"rowkey VARCHAR PRIMARY KEY,\n" +
+"c1 VARCHAR,\n" +
+"c2 VARCHAR)");
+conn.createStatement().execute("CREATE LOCAL INDEX
test4388_c1_idx ON test4288 (c1)");
+
--- End diff --
How about getting the explain plan here and verify that it's doing a full
table scan (i.e. before there are any stats available)?
---
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014126
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/HashJoinPlan.java ---
@@ -290,6 +291,25 @@ public FilterableStatement getStatement() {
return statement;
}
+@Override
+public Cost getCost() throws SQLException {
+Long byteCount = getEstimatedBytesToScan();
+if (byteCount == null) {
+return Cost.ZERO;
+}
+
+Cost cost = new Cost(0, 0, byteCount);
+Cost lhsCost = delegate.getCost();
+if (keyRangeExpressions != null) {
+lhsCost = lhsCost.multiplyBy(0.01);
--- End diff --
Why the 0.01? More comments would be good.
---
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151012292
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,50 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Properties;
+
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.junit.Test;
+
+public class CostBasedDecisionIT extends ParallelStatsEnabledIT {
+
+@Test
+public void testBug4288() throws Exception {
+Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
+Connection conn = DriverManager.getConnection(getUrl(), props);
+conn.setAutoCommit(true);
+try {
+conn.createStatement().execute("CREATE TABLE test4288 (\n" +
--- End diff --
Make sure to generate a unique name for your table (see other tests for
examples)
---
[GitHub] phoenix pull request #281: PHOENIX-4288 Indexes not used when ordering by pr...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r151014001
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/execute/BaseQueryPlan.java ---
@@ -500,7 +500,10 @@ public ExplainPlan getExplainPlan() throws
SQLException {
if (context.getScanRanges() == ScanRanges.NOTHING) {
return new ExplainPlan(Collections.singletonList("DEGENERATE
SCAN OVER " + getTableRef().getTable().getName().getString()));
}
-
+
+// Initialize dummy iterator to get the stats.
--- End diff --
Comment that you need the stats prior to optimization as they help drive
cost based decisions.
---
[jira] [Commented] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views and not for indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252761#comment-16252761 ] James Taylor commented on PHOENIX-4379: --- +1. Nice find, [~tdsilva]. > Upgrade code to create CHILD links should only create the links for views and > not for indexes > - > > Key: PHOENIX-4379 > URL: https://issues.apache.org/jira/browse/PHOENIX-4379 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.13.1 > > Attachments: PHOENIX-4279.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4322) DESC primary key column with variable length does not work in SkipScanFilter
[
https://issues.apache.org/jira/browse/PHOENIX-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252757#comment-16252757
]
James Taylor commented on PHOENIX-4322:
---
I thought you were planning on looking at making sure that RVCs don't write
trailing separator bytes, [~maryannxue]?
> DESC primary key column with variable length does not work in SkipScanFilter
>
>
> Key: PHOENIX-4322
> URL: https://issues.apache.org/jira/browse/PHOENIX-4322
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Fix For: 4.14.0
>
>
> Example:
> {code}
> @Test
> public void inDescCompositePK3() throws Exception {
> String table = generateUniqueName();
> String ddl = "CREATE table " + table + " (oid VARCHAR NOT NULL, code
> VARCHAR NOT NULL constraint pk primary key (oid DESC, code DESC))";
> Object[][] insertedRows = new Object[][]{{"o1", "1"}, {"o2", "2"},
> {"o3", "3"}};
> runQueryTest(ddl, upsert("oid", "code"), insertedRows, new
> Object[][]{{"o2", "2"}, {"o1", "1"}}, new WhereCondition("(oid, code)", "IN",
> "(('o2', '2'), ('o1', '1'))"),
> table);
> }
> {code}
> Here the last column in primary key is in DESC order and has variable length,
> and WHERE clause involves an "IN" operator with RowValueConstructor
> specifying all PK columns. We get no results.
> This ends up being the root cause for not being able to use child/parent join
> optimization on DESC pk columns as described in PHOENIX-3050.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views and not for indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4379: Attachment: PHOENIX-4279.patch [~jamestaylor] Can you please review? > Upgrade code to create CHILD links should only create the links for views and > not for indexes > - > > Key: PHOENIX-4379 > URL: https://issues.apache.org/jira/browse/PHOENIX-4379 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.13.1 > > Attachments: PHOENIX-4279.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4380) Add upgrade code to remove child links to index tables that were created incorrectly in 4.11
[ https://issues.apache.org/jira/browse/PHOENIX-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4380: Affects Version/s: 4.11.0 > Add upgrade code to remove child links to index tables that were created > incorrectly in 4.11 > > > Key: PHOENIX-4380 > URL: https://issues.apache.org/jira/browse/PHOENIX-4380 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva > Fix For: 4.14.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4380) Add upgrade code to remove child links to index tables that were created incorrectly in 4.11
[ https://issues.apache.org/jira/browse/PHOENIX-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4380: Fix Version/s: 4.14.0 > Add upgrade code to remove child links to index tables that were created > incorrectly in 4.11 > > > Key: PHOENIX-4380 > URL: https://issues.apache.org/jira/browse/PHOENIX-4380 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva > Fix For: 4.14.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4380) Add upgrade code to remove child links to index tables that were created incorrectly in 4.11
Thomas D'Silva created PHOENIX-4380: --- Summary: Add upgrade code to remove child links to index tables that were created incorrectly in 4.11 Key: PHOENIX-4380 URL: https://issues.apache.org/jira/browse/PHOENIX-4380 Project: Phoenix Issue Type: Bug Reporter: Thomas D'Silva -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views and not for indexes
[ https://issues.apache.org/jira/browse/PHOENIX-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-4379: Summary: Upgrade code to create CHILD links should only create the links for views and not for indexes (was: Upgrade code to create CHILD links should only create the links for views) > Upgrade code to create CHILD links should only create the links for views and > not for indexes > - > > Key: PHOENIX-4379 > URL: https://issues.apache.org/jira/browse/PHOENIX-4379 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0 >Reporter: Thomas D'Silva >Assignee: Thomas D'Silva > Fix For: 4.13.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4360) Prevent System.Catalog from splitting
[ https://issues.apache.org/jira/browse/PHOENIX-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4360: --- Fix Version/s: 4.14.0 > Prevent System.Catalog from splitting > - > > Key: PHOENIX-4360 > URL: https://issues.apache.org/jira/browse/PHOENIX-4360 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0 >Reporter: Lars Hofhansl >Priority: Blocker > Fix For: 4.14.0 > > > Just talked to [~jamestaylor]. > It turns out that currently System.Catalog is not prevented from splitting > generally, but does not allow splitting within a schema. > In the multi-tenant case that is not good enough. When System.Catalog splits > and a base table and view end up in different regions the following can > happen: > * DROP CASCADE no longer works for those views > * Adding/removing columns to/from the base table no longer works > Until PHOENIX-3534 is done we should simply prevent System.Catalog from > splitting. (just like HBase:meta) > [~apurtell] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4360) Prevent System.Catalog from splitting
[ https://issues.apache.org/jira/browse/PHOENIX-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252644#comment-16252644 ] Lars Hofhansl commented on PHOENIX-4360: Upping to release blocker. DROP CASCADE or most DDL on views/tables can more or less just fail randomly. Either we get PHOENIX-3534 in or we have to stop SYSTEM.CATALOG from splitting (much HBase:meta) > Prevent System.Catalog from splitting > - > > Key: PHOENIX-4360 > URL: https://issues.apache.org/jira/browse/PHOENIX-4360 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0 >Reporter: Lars Hofhansl >Priority: Blocker > > Just talked to [~jamestaylor]. > It turns out that currently System.Catalog is not prevented from splitting > generally, but does not allow splitting within a schema. > In the multi-tenant case that is not good enough. When System.Catalog splits > and a base table and view end up in different regions the following can > happen: > * DROP CASCADE no longer works for those views > * Adding/removing columns to/from the base table no longer works > Until PHOENIX-3534 is done we should simply prevent System.Catalog from > splitting. (just like HBase:meta) > [~apurtell] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4360) Prevent System.Catalog from splitting
[ https://issues.apache.org/jira/browse/PHOENIX-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-4360: --- Priority: Blocker (was: Critical) > Prevent System.Catalog from splitting > - > > Key: PHOENIX-4360 > URL: https://issues.apache.org/jira/browse/PHOENIX-4360 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.13.0 >Reporter: Lars Hofhansl >Priority: Blocker > > Just talked to [~jamestaylor]. > It turns out that currently System.Catalog is not prevented from splitting > generally, but does not allow splitting within a schema. > In the multi-tenant case that is not good enough. When System.Catalog splits > and a base table and view end up in different regions the following can > happen: > * DROP CASCADE no longer works for those views > * Adding/removing columns to/from the base table no longer works > Until PHOENIX-3534 is done we should simply prevent System.Catalog from > splitting. (just like HBase:meta) > [~apurtell] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4379) Upgrade code to create CHILD links should only create the links for views
Thomas D'Silva created PHOENIX-4379: --- Summary: Upgrade code to create CHILD links should only create the links for views Key: PHOENIX-4379 URL: https://issues.apache.org/jira/browse/PHOENIX-4379 Project: Phoenix Issue Type: Bug Affects Versions: 4.11.0 Reporter: Thomas D'Silva Assignee: Thomas D'Silva Fix For: 4.13.1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4322) DESC primary key column with variable length does not work in SkipScanFilter
[
https://issues.apache.org/jira/browse/PHOENIX-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252194#comment-16252194
]
Maryann Xue commented on PHOENIX-4322:
--
[~jamestaylor] Did you have time to take a look?
> DESC primary key column with variable length does not work in SkipScanFilter
>
>
> Key: PHOENIX-4322
> URL: https://issues.apache.org/jira/browse/PHOENIX-4322
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Fix For: 4.14.0
>
>
> Example:
> {code}
> @Test
> public void inDescCompositePK3() throws Exception {
> String table = generateUniqueName();
> String ddl = "CREATE table " + table + " (oid VARCHAR NOT NULL, code
> VARCHAR NOT NULL constraint pk primary key (oid DESC, code DESC))";
> Object[][] insertedRows = new Object[][]{{"o1", "1"}, {"o2", "2"},
> {"o3", "3"}};
> runQueryTest(ddl, upsert("oid", "code"), insertedRows, new
> Object[][]{{"o2", "2"}, {"o1", "1"}}, new WhereCondition("(oid, code)", "IN",
> "(('o2', '2'), ('o1', '1'))"),
> table);
> }
> {code}
> Here the last column in primary key is in DESC order and has variable length,
> and WHERE clause involves an "IN" operator with RowValueConstructor
> specifying all PK columns. We get no results.
> This ends up being the root cause for not being able to use child/parent join
> optimization on DESC pk columns as described in PHOENIX-3050.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4321) Replace deprecated HBaseAdmin with Admin
[ https://issues.apache.org/jira/browse/PHOENIX-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252185#comment-16252185 ] Josh Elser commented on PHOENIX-4321: - Looks good. Thanks Sergey! > Replace deprecated HBaseAdmin with Admin > > > Key: PHOENIX-4321 > URL: https://issues.apache.org/jira/browse/PHOENIX-4321 > Project: Phoenix > Issue Type: Sub-task >Reporter: Sergey Soldatov >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 4.14.0 > > Attachments: PHOENIX-4321.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4373) Local index variable length key can have trailing nulls while upserting
[ https://issues.apache.org/jira/browse/PHOENIX-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252161#comment-16252161 ] Hudson commented on PHOENIX-4373: - FAILURE: Integrated in Jenkins build Phoenix-master #1873 (See [https://builds.apache.org/job/Phoenix-master/1873/]) PHOENIX-4373 Local index variable length key can have trailing nulls (vincentpoon: rev b2d5b4d75d4698981b291fecfac3efa3fb6e2649) * (edit) phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexToolIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/compile/ScanRanges.java > Local index variable length key can have trailing nulls while upserting > --- > > Key: PHOENIX-4373 > URL: https://issues.apache.org/jira/browse/PHOENIX-4373 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Fix For: 5.0, 4.14.0 > > Attachments: PHOENIX-4373.v1.master.patch > > > In the UpsertCompiler#setValues() , if it's a local index, the key is > prefixed with regionPrefix. During that process, ptr.get() is called to get > the base key, and the code assumes the entire array should be used. However, > if it's a variable length key, we could have trailing nulls since the base > key ptr array size is just an estimate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4325) Make use of TableName POJO in HBase where ever possible.
[ https://issues.apache.org/jira/browse/PHOENIX-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252143#comment-16252143 ] Sergey Soldatov commented on PHOENIX-4325: -- [~elserj] Ah, I've commented on another issue about it. It's not critical and will involve a lot of changes on different levels. And it's not clear how to properly handle it (TableName has a notion of schema already, but in Phoenix whether we can use it depends on the isNamespaceMapped property and all those changes need to be tested carefully). Changes for Admin stuff are all in PHOENIX-4321. If there are other places that need to use TableName it's better to use TableName.valueOf (whether String or byte array here) atm. Once we get everything compiled and working we may proceed with this jira. > Make use of TableName POJO in HBase where ever possible. > > > Key: PHOENIX-4325 > URL: https://issues.apache.org/jira/browse/PHOENIX-4325 > Project: Phoenix > Issue Type: Sub-task >Reporter: Rajeshbabu Chintaguntla >Assignee: Sergey Soldatov > Labels: HBase-2.0 > Fix For: 4.14.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4325) Make use of TableName POJO in HBase where ever possible.
[
https://issues.apache.org/jira/browse/PHOENIX-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252096#comment-16252096
]
Josh Elser commented on PHOENIX-4325:
-
[~sergey.soldatov], is this one close? I'm just looking at the current
compilation issues on 5.x-HBase-2.0 and noticing that we have some TableName
related issues (e.g. {{Admin#tableExists(String)}} was removed).
Might I suggest that if this is still far away from completion, we split up the
work into two issues? 1) for the minimal String->TableName changes to unblock
compilation 2) Converging Phoenix on TableName all around.
> Make use of TableName POJO in HBase where ever possible.
>
>
> Key: PHOENIX-4325
> URL: https://issues.apache.org/jira/browse/PHOENIX-4325
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Sergey Soldatov
> Labels: HBase-2.0
> Fix For: 4.14.0
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4370) Surface hbase metrics from perconnection to global metrics
[ https://issues.apache.org/jira/browse/PHOENIX-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251972#comment-16251972 ] Ethan Wang commented on PHOENIX-4370: - [~alexaraujo] > Surface hbase metrics from perconnection to global metrics > -- > > Key: PHOENIX-4370 > URL: https://issues.apache.org/jira/browse/PHOENIX-4370 > Project: Phoenix > Issue Type: Bug >Reporter: Ethan Wang >Assignee: Ethan Wang > > Surface hbase metrics from perconnection to global metrics -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PHOENIX-4324) Immutable indexes are invalid with null fixed width indexed column values
[
https://issues.apache.org/jira/browse/PHOENIX-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251880#comment-16251880
]
James Taylor edited comment on PHOENIX-4324 at 11/14/17 6:27 PM:
-
This has the potential to break functionality that uses the meta data in the
SYSTEM.CATALOG to interpret the row key. The fundamental issue is that the data
type use by the IndexMaintainer does not match the "source of truth" type in
the system catalog. The IndexMaintainer should translate the data type using
IndexUtil.getIndexColumnDataType(). It's unclear why this is happening for
mutable but not immutable indexes.
The reason we do this translation from fixed width type to variable width type
is so that we can handle null correctly. When a KeyValue column is indexed, it
can be absent in the data table row and thus have a null value for the column
in the row key for the index row. Fixed width types do not have a way to
represent null, while variable length types do - any empty byte represents null
for all variable length types.
An example would be as follows:
{code}
CREATE IMMUTABLE TABLE T (K VARCHAR PRIMARY KEY, V1 SMALLINT);
CREATE INDEX IDX ON T(V1);
{code}
The expected row key structure of the index would be DECIMAL+VARCHAR, but
instead the IndexMaintainer ends up writing the data as SMALLINT+VARCHAR. Since
DECIMAL is variable length, the index row key can lead with a \0 byte for rows
in the data table that don't have a V1 value. As a SMALLINT, I'm not entirely
sure what would be used - maybe 2 \0 bytes.
A simple query that uses the index would still work because we always coerce
the index data type to the data table type. In this case, due to this bug, the
coerce would be a noop and it appears to work.
I suspect the following types of things would not function correctly:
- queries that use IS NULL will not always work, depending on the value of V1.
I suspect negative numbers would be problematic. Definitely a value of
Short.MIN_VALUE would be a problem.
- queries that compute some expression with V1 instead of just selecting it
would probably not work. For example, SELECT V1 + 5 FROM T WHERE V1 > 100.
- query more functionality that uses the index may not function correctly (as I
believe query more relies on the data type from the index table row in system
catalog).
There are two ways I can think of to fix the problem (and both need to be done
IMHO):
# Support declaring non PK columns as NOT NULL for immutable tables
(PHOENIX-2566) and modify the index meta data to use the same type as the data
table column type. If a column is NOT NULL, then we can keep the same data type
between the index and data table. This solution is attractive because we do not
need to recreate the index as it's purely modifying the meta data.
# Fix the IndexMaintainer code to do the correct data type adjustment for
immutable tables and disable (or asynchronously rebuild) all immutable indexes.
We need to do this in a b/w compatible manner, though, so we'd need to continue
to generate the "incorrect" row key schema in the IndexMaintainer until the
index gets rebuilt. We could use a dynamic column in the index table header row
in system catalog to track this.
was (Author: jamestaylor):
This has the potential to break functionality that uses the meta data in the
SYSTEM.CATALOG to interpret the row key. The fundamental issue is that the data
type use by the IndexMaintainer does not match the "source of truth" type in
the system catalog. The IndexMaintainer should translate the data type using
IndexUtil.getIndexColumnDataType(). It's unclear why this is happening for
mutable but not immutable indexes.
The reason we do this translation from fixed width type to variable width type
is so that we can handle null correctly. When a KeyValue column is indexed, it
can be absent in the data table row and thus have a null value for the column
in the row key for the index row. Fixed width types do not have a way to
represent null, while variable length types do - any empty byte represents null
for all variable length types.
An example would be as follows:
{code}
CREATE IMMUTABLE TABLE T (K VARCHAR PRIMARY KEY, V1 SMALLINT);
CREATE INDEX IDX ON T(V1);
{code}
The expected row key structure of the index would be DECIMAL+VARCHAR, but
instead the IndexMaintainer ends up writing the data as SMALLINT+VARCHAR. Since
DECIMAL is variable length, the index row key can lead with a \0 byte for rows
in the data table that don't have a V1 value. As a SMALLINT, I'm not entirely
sure what would be used - maybe 2 \0 bytes.
A simple query that uses the index would still work because we always coerce
the index data type to the data table type. In this case, due to this bug, the
coerce would be a noop and it appears to work.
I suspect the following types of things would not function correctly:
- queries that use
[jira] [Commented] (PHOENIX-4324) Immutable indexes are invalid with null fixed width indexed column values
[
https://issues.apache.org/jira/browse/PHOENIX-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251880#comment-16251880
]
James Taylor commented on PHOENIX-4324:
---
This has the potential to break functionality that uses the meta data in the
SYSTEM.CATALOG to interpret the row key. The fundamental issue is that the data
type use by the IndexMaintainer does not match the "source of truth" type in
the system catalog. The IndexMaintainer should translate the data type using
IndexUtil.getIndexColumnDataType(). It's unclear why this is happening for
mutable but not immutable indexes.
The reason we do this translation from fixed width type to variable width type
is so that we can handle null correctly. When a KeyValue column is indexed, it
can be absent in the data table row and thus have a null value for the column
in the row key for the index row. Fixed width types do not have a way to
represent null, while variable length types do - any empty byte represents null
for all variable length types.
An example would be as follows:
{code}
CREATE IMMUTABLE TABLE T (K VARCHAR PRIMARY KEY, V1 SMALLINT);
CREATE INDEX IDX ON T(V1);
{code}
The expected row key structure of the index would be DECIMAL+VARCHAR, but
instead the IndexMaintainer ends up writing the data as SMALLINT+VARCHAR. Since
DECIMAL is variable length, the index row key can lead with a \0 byte for rows
in the data table that don't have a V1 value. As a SMALLINT, I'm not entirely
sure what would be used - maybe 2 \0 bytes.
A simple query that uses the index would still work because we always coerce
the index data type to the data table type. In this case, due to this bug, the
coerce would be a noop and it appears to work.
I suspect the following types of things would not function correctly:
- queries that use IS NULL will not always work, depending on the value of V1.
I suspect negative numbers would be problematic. Definitely a value of
Short.MIN_VALUE would be a problem.
- queries that compute some expression with V1 instead of just selecting it
would probably not work. For example, SELECT V1 + 5 FROM T WHERE V1 > 100.
- query more functionality that uses the index may not function correctly (as I
believe query more relies on the data type from the index table row in system
catalog).
> Immutable indexes are invalid with null fixed width indexed column values
> -
>
> Key: PHOENIX-4324
> URL: https://issues.apache.org/jira/browse/PHOENIX-4324
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>
> The data conversion for fixed width column types is not being done for
> immutable indexes leading to erroneous results when indexed columns are
> absent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4324) Immutable indexes are invalid with null fixed width indexed column values
[ https://issues.apache.org/jira/browse/PHOENIX-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor reassigned PHOENIX-4324: - Assignee: (was: James Taylor) > Immutable indexes are invalid with null fixed width indexed column values > - > > Key: PHOENIX-4324 > URL: https://issues.apache.org/jira/browse/PHOENIX-4324 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor > > The data conversion for fixed width column types is not being done for > immutable indexes leading to erroneous results when indexed columns are > absent. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4373) Local index variable length key can have trailing nulls while upserting
[ https://issues.apache.org/jira/browse/PHOENIX-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251778#comment-16251778 ] James Taylor commented on PHOENIX-4373: --- +1. Nice work, [~vincentpoon]. > Local index variable length key can have trailing nulls while upserting > --- > > Key: PHOENIX-4373 > URL: https://issues.apache.org/jira/browse/PHOENIX-4373 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0 >Reporter: Vincent Poon >Assignee: Vincent Poon > Attachments: PHOENIX-4373.v1.master.patch > > > In the UpsertCompiler#setValues() , if it's a local index, the key is > prefixed with regionPrefix. During that process, ptr.get() is called to get > the base key, and the code assumes the entire array should be used. However, > if it's a variable length key, we could have trailing nulls since the base > key ptr array size is just an estimate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4376) Fix all compilation error for package org.apache.phoenix.schema.stats and org.apache.phoenix.coprocessor
[
https://issues.apache.org/jira/browse/PHOENIX-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251720#comment-16251720
]
Josh Elser commented on PHOENIX-4376:
-
{code}
+ if (scan.isRaw() ||
ScanInfoUtil.isKeepDeletedCells(((HStore)store).getScanInfo()) ||
scan.getTimeRange().getMax() == HConstants.LATEST_TIMESTAMP ||
TransactionUtil.isTransactionalTimestamp(scan.getTimeRange().getMax())) {
{code}
We should get rid of the {{((HStore) store).getScanInfo()}}. Can you switch
{{ScanInfoUtil.isKeepDeleteCells}} to take a {{Store}} and have the method use
{{store.getColumnFamilyDescriptor().getKeepDeletedCells()}} instead?
+1 otherwise.
> Fix all compilation error for package org.apache.phoenix.schema.stats and
> org.apache.phoenix.coprocessor
>
>
> Key: PHOENIX-4376
> URL: https://issues.apache.org/jira/browse/PHOENIX-4376
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Labels: HBase-2.0
> Fix For: 5.0.0
>
> Attachments: PHOENIX-4376.patch
>
>
> -- It includes updating the coprocessor hook with right definition.
> -- Changing HRegionInfo to RegionInfo.
> -- Cell related changes.
> Like
> {code}
> -byte[] viewConstant = viewConstantKv == null ? null :
> viewConstantKv.getValue();
> +byte[] viewConstant = viewConstantKv == null ? null :
> CellUtil.cloneValue(viewConstantKv);
> -Cell viewStatementCell = new KeyValue(cell.getRow(),
> cell.getFamily(), VIEW_STATEMENT_BYTES,
> +Cell viewStatementCell = new
> KeyValue(CellUtil.cloneRow(cell), CellUtil.cloneFamily(cell),
> VIEW_STATEMENT_BYTES,
> {code}
> -- Update scan
> {code}
> -scan.setStartRow(HConstants.EMPTY_START_ROW);
> -scan.setStopRow(HConstants.EMPTY_END_ROW);
> +scan.withStartRow(HConstants.EMPTY_START_ROW);
> +scan.withStopRow(HConstants.EMPTY_END_ROW);
> {code}
> -- preSplit hook needs to be removed and fixed in PHOENIX-4352.
> -- Requires a separate fix of PHOENIX-4277 and PHOENIX-3081 for HBase 2.0
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (PHOENIX-4378) port PHOENIX-4277 for HBase-2.0
Ankit Singhal created PHOENIX-4378: -- Summary: port PHOENIX-4277 for HBase-2.0 Key: PHOENIX-4378 URL: https://issues.apache.org/jira/browse/PHOENIX-4378 Project: Phoenix Issue Type: Bug Reporter: Ankit Singhal Fix For: 5.0.0 [~jamestaylor], It seems we may need to fix PHOENIX-4277 differently for HBase 2.0 as we can only update TTL and maxVersions now in preStoreScannerOpen and cannot return a new StoreScanner with updated scanInfo. for reference: [1]https://issues.apache.org/jira/browse/PHOENIX-4318?focusedCommentId=16249943=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16249943 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4377) Port PHOENIX-3081 to HBase-2.0
[ https://issues.apache.org/jira/browse/PHOENIX-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4377: --- Labels: HBase-2.0 (was: ) > Port PHOENIX-3081 to HBase-2.0 > -- > > Key: PHOENIX-4377 > URL: https://issues.apache.org/jira/browse/PHOENIX-4377 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Attachments: PHOENIX-4377.patch > > > -- RegionServerService is not exposed by RegionCoprocessorEnvironment now. > -- Need to update the Mock tests accordingly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4377) Port PHOENIX-3081 to HBase-2.0
[ https://issues.apache.org/jira/browse/PHOENIX-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated PHOENIX-4377: --- Attachment: PHOENIX-4377.patch FYI , [~elserj] I'll update test case once main code started compiling. > Port PHOENIX-3081 to HBase-2.0 > -- > > Key: PHOENIX-4377 > URL: https://issues.apache.org/jira/browse/PHOENIX-4377 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Attachments: PHOENIX-4377.patch > > > -- RegionServerService is not exposed by RegionCoprocessorEnvironment now. > -- Need to update the Mock tests accordingly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4377) Port PHOENIX-3081 to HBase-2.0
Ankit Singhal created PHOENIX-4377: -- Summary: Port PHOENIX-3081 to HBase-2.0 Key: PHOENIX-4377 URL: https://issues.apache.org/jira/browse/PHOENIX-4377 Project: Phoenix Issue Type: Bug Reporter: Ankit Singhal Assignee: Ankit Singhal -- RegionServerService is not exposed by RegionCoprocessorEnvironment now. -- Need to update the Mock tests accordingly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4376) Fix all compilation error for package org.apache.phoenix.schema.stats and org.apache.phoenix.coprocessor
Ankit Singhal created PHOENIX-4376:
--
Summary: Fix all compilation error for package
org.apache.phoenix.schema.stats and org.apache.phoenix.coprocessor
Key: PHOENIX-4376
URL: https://issues.apache.org/jira/browse/PHOENIX-4376
Project: Phoenix
Issue Type: Sub-task
Reporter: Ankit Singhal
Assignee: Ankit Singhal
Fix For: 5.0.0
-- It includes updating the coprocessor hook with right definition.
-- Changing HRegionInfo to RegionInfo.
-- Cell related changes.
Like
{code}
-byte[] viewConstant = viewConstantKv == null ? null :
viewConstantKv.getValue();
+byte[] viewConstant = viewConstantKv == null ? null :
CellUtil.cloneValue(viewConstantKv);
-Cell viewStatementCell = new KeyValue(cell.getRow(),
cell.getFamily(), VIEW_STATEMENT_BYTES,
+Cell viewStatementCell = new
KeyValue(CellUtil.cloneRow(cell), CellUtil.cloneFamily(cell),
VIEW_STATEMENT_BYTES,
{code}
-- Update scan
{code}
-scan.setStartRow(HConstants.EMPTY_START_ROW);
-scan.setStopRow(HConstants.EMPTY_END_ROW);
+scan.withStartRow(HConstants.EMPTY_START_ROW);
+scan.withStopRow(HConstants.EMPTY_END_ROW);
{code}
-- preSplit hook needs to be removed and fixed in PHOENIX-4352.
-- Requires a separate fix of PHOENIX-4277 and PHOENIX-3081 for HBase 2.0
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4375) Replace deprecated or changed Scan methods with new APIs
[ https://issues.apache.org/jira/browse/PHOENIX-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal reassigned PHOENIX-4375: -- Assignee: Ankit Singhal (was: Rajeshbabu Chintaguntla) > Replace deprecated or changed Scan methods with new APIs > > > Key: PHOENIX-4375 > URL: https://issues.apache.org/jira/browse/PHOENIX-4375 > Project: Phoenix > Issue Type: Sub-task >Reporter: Rajeshbabu Chintaguntla >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 4.14.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4318) Fix IndexHalfStoreFileReader and related classes
[ https://issues.apache.org/jira/browse/PHOENIX-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla reassigned PHOENIX-4318: Assignee: Rajeshbabu Chintaguntla (was: rajeshbabu) > Fix IndexHalfStoreFileReader and related classes > > > Key: PHOENIX-4318 > URL: https://issues.apache.org/jira/browse/PHOENIX-4318 > Project: Phoenix > Issue Type: Sub-task >Reporter: Ankit Singhal >Assignee: Rajeshbabu Chintaguntla > Labels: HBase-2.0 > Fix For: 4.14.0 > > Attachments: PHOENIX-4318_wip.patch, PHOENIX-4318_wip3.patch > > > These classes use the internals of HBase.(And most of them are not accessible > in HBase 2.0) > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReader.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReaderGenerator.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionScanner.java > phoenix-core/src/main/java/org/apache/phoenix/util/IndexUtil.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PHOENIX-4318) Fix IndexHalfStoreFileReader and related classes
[ https://issues.apache.org/jira/browse/PHOENIX-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal reassigned PHOENIX-4318: -- Assignee: rajeshbabu (was: Ankit Singhal) > Fix IndexHalfStoreFileReader and related classes > > > Key: PHOENIX-4318 > URL: https://issues.apache.org/jira/browse/PHOENIX-4318 > Project: Phoenix > Issue Type: Sub-task >Reporter: Ankit Singhal >Assignee: rajeshbabu > Labels: HBase-2.0 > Fix For: 4.14.0 > > Attachments: PHOENIX-4318_wip.patch, PHOENIX-4318_wip3.patch > > > These classes use the internals of HBase.(And most of them are not accessible > in HBase 2.0) > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReader.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReaderGenerator.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionScanner.java > phoenix-core/src/main/java/org/apache/phoenix/util/IndexUtil.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4318) Fix IndexHalfStoreFileReader and related classes
[ https://issues.apache.org/jira/browse/PHOENIX-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251079#comment-16251079 ] Ankit Singhal commented on PHOENIX-4318: Thanks [~anoop.hbase] for the confirmation. Actually, this is how currently the local index implemented. bq. Its really getting tough to have a StoreFileReader version of our own. I know why Phoenix is having one. We should see whether/how we can avoid this. bq. We don't expect CP users to create own StoreScanner object. Not giving a way just to change the Store level scanner. The wrap can be done at a higher level at Region scanner layer alone now. What is the usage to just handle one Store for this Store scanner? [~rajeshbabu], as you more aware of local index implementation, assigning to you for making the changes from here onwards. > Fix IndexHalfStoreFileReader and related classes > > > Key: PHOENIX-4318 > URL: https://issues.apache.org/jira/browse/PHOENIX-4318 > Project: Phoenix > Issue Type: Sub-task >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Labels: HBase-2.0 > Fix For: 4.14.0 > > Attachments: PHOENIX-4318_wip.patch, PHOENIX-4318_wip3.patch > > > These classes use the internals of HBase.(And most of them are not accessible > in HBase 2.0) > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReader.java > phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexHalfStoreFileReaderGenerator.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionScanner.java > phoenix-core/src/main/java/org/apache/phoenix/util/IndexUtil.java > phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
