[
https://issues.apache.org/jira/browse/PHOENIX-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370819#comment-17370819
]
ASF GitHub Bot commented on PHOENIX-6458:
-----------------------------------------
lhofhansl commented on a change in pull request #1256:
URL: https://github.com/apache/phoenix/pull/1256#discussion_r660057634
##########
File path: phoenix-core/src/main/java/org/apache/phoenix/util/IndexUtil.java
##########
@@ -574,20 +575,35 @@ public static void wrapResultUsingOffset(final
RegionCoprocessorEnvironment envi
}
}
Result joinResult = null;
- if (dataRegion != null) {
- joinResult = dataRegion.get(get);
- } else {
- TableName dataTable =
-
TableName.valueOf(MetaDataUtil.getLocalIndexUserTableName(environment.getRegion().
-
getTableDescriptor().getTableName().getNameAsString()));
+ if (ScanUtil.isLocalIndex(scan)) {
+ if (dataRegion != null) {
+ joinResult = dataRegion.get(get);
+ } else {
+ TableName dataTable =
+
TableName.valueOf(MetaDataUtil.getLocalIndexUserTableName(environment.getRegion().
+
getTableDescriptor().getTableName().getNameAsString()));
+ Table table = null;
+ try {
+ table =
environment.getConnection().getTable(dataTable);
+ joinResult = table.get(get);
+ } finally {
+ if (table != null) table.close();
+ }
+ }
+ } else if (ScanUtil.isGlobalIndex(scan)) {
+ byte[] dataTableName =
scan.getAttribute(PHYSICAL_DATA_TABLE_NAME);
Table table = null;
try {
- table = environment.getConnection().getTable(dataTable);
+ table = ServerUtil.ConnectionFactory.
+
getConnection(ServerUtil.ConnectionType.INDEX_WRITER_CONNECTION, environment).
+ getTable(TableName.valueOf(dataTableName));
joinResult = table.get(get);
Review comment:
I think that's perfectly fine to do in a separate PR.
And, yes, doing buffering will require quite some refactoring, since you (a)
have to do it at a place where you still know the rows involved, and (b) a
level higher than here, so that you can buffer.
The only concern I have that in case using an index can be significantly
slower than a full scan (this is true even for local indexes). For example a
query of the form SELECT colA FROM table WHERE colB > 0; assuming colB is not
selective will take longer. Note that FAST_DIFF (unfortunately Phoenix'
default) is particularly slow for Get operations. My guess is that with
defaults if the WHERE is not 99% - 99.9% selective, the query might be slower.
In any case :) Another PR is cool.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Using global indexes for queries with uncovered columns
> -------------------------------------------------------
>
> Key: PHOENIX-6458
> URL: https://issues.apache.org/jira/browse/PHOENIX-6458
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.1.0
> Reporter: Kadir Ozdemir
> Priority: Major
> Attachments: PHOENIX-6458.master.001.patch
>
>
> Phoenix client does not use a global index for the queries with the columns
> that are not covered by the global index. However, there are many cases where
> using the global index to map secondary keys to primary keys and then
> retrieving the corresponding rows from the data table results in faster
> queries. It is expected that such performance improvement will happen when
> the index row key prefix length is greater than the data row key prefix
> length for a given query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
