Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14762643
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/compile/TrackOrderPreservingExpressionCompiler.java
---
@@ -69,6 +70,7 @@
boolean isSharedViewIndex = table.getViewIndexId() != null;
// TODO: util for this offset, as it's computed in numerous places
positionOffset = (isSalted ? 1 : 0) + (isMultiTenant ? 1 : 0) +
(isSharedViewIndex ? 1 : 0);
+ this.isOrderPreserving &= table.getIndexType() != IndexType.LOCAL;
--- End diff --
One thing that's necessary, though, to maintain rows in row key order is to
modify ScanPlan.java:118 to do a merge sort instead of a concat:
if ((isSalted || isLocalIndex) &&
(context.getConnection().getQueryServices().getProps().getBoolean(
QueryServices.ROW_KEY_ORDER_SALTED_TABLE_ATTRIB,
QueryServicesOptions.DEFAULT_ROW_KEY_ORDER_SALTED_TABLE) ||
orderBy == OrderBy.FWD_ROW_KEY_ORDER_BY ||
orderBy == OrderBy.REV_ROW_KEY_ORDER_BY)) { // ORDER
BY was optimized out b/c query is in row key order
scanner = new MergeSortRowKeyResultIterator(iterators,
SaltingUtil.NUM_SALTING_BYTES, orderBy == OrderBy.REV_ROW_KEY_ORDER_BY);
} else {
scanner = new ConcatResultIterator(iterators);
}
Local indexes are similar to salted tables in that the parallel scans will
all be within a region, ordered correctly. As long as we do a merge sort across
the results of these scans, the rows will be ordered correctly.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
