git commit: PHOENIX-1100 Upsert Select with Sequence and Order By doesn't result in sequence getting assigned based on requested ordering

[ja...@apache.org]

Repository: phoenix
Updated Branches:
  refs/heads/3.0 1483998e5 -> 84dce4022


PHOENIX-1100 Upsert Select with Sequence and Order By doesn't result in sequence getting assigned based on requested ordering


Project: http://git-wip-us.apache.org/repos/asf/phoenix/repo
Commit: http://git-wip-us.apache.org/repos/asf/phoenix/commit/84dce402
Tree: http://git-wip-us.apache.org/repos/asf/phoenix/tree/84dce402
Diff: http://git-wip-us.apache.org/repos/asf/phoenix/diff/84dce402

Branch: refs/heads/3.0
Commit: 84dce40225c540f2b85975ffc6b2dd834e4f367c
Parents: 1483998
Author: James Taylor <jt...@salesforce.com>
Authored: Sat Jul 19 18:19:39 2014 -0700
Committer: James Taylor <jt...@salesforce.com>
Committed: Sat Jul 19 18:19:39 2014 -0700

----------------------------------------------------------------------
 .../main/java/org/apache/phoenix/compile/UpsertCompiler.java   | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/phoenix/blob/84dce402/phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java
----------------------------------------------------------------------
diff --git a/phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java b/phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java
index d0d53ab..52cf7d3 100644
--- a/phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java
+++ b/phoenix-core/src/main/java/org/apache/phoenix/compile/UpsertCompiler.java
@@ -360,7 +360,7 @@ public class UpsertCompiler {
              * 1) from has only 1 table and the into table matches from table
              * 2) the select query isn't doing aggregation (which requires a client-side final merge)
              * 3) autoCommit is on
-             * 4) the table is not immutable, as the client is the one that figures out the additional
+             * 4) the table is not immutable with indexes, as the client is the one that figures out the additional
              *    puts for index tables.
              * 5) no limit clause, as the limit clause requires client-side post processing
              * 6) no sequences, as sequences imply that the order of upsert must match the order of
@@ -368,7 +368,6 @@ public class UpsertCompiler {
              * Otherwise, run the query to pull the data from the server
              * and populate the MutationState (upto a limit).
             */            
-            runOnServer = sameTable && isAutoCommit && !table.isImmutableRows() && !select.isAggregate() && !select.isDistinct() && select.getLimit() == null && table.getBucketNum() == null;
             ParallelIteratorFactory parallelIteratorFactory;
             if (select.isAggregate() || select.isDistinct() || select.getLimit() != null || select.hasSequence()) {
                 parallelIteratorFactory = null;
@@ -376,6 +375,9 @@ public class UpsertCompiler {
                 // We can pipeline the upsert select instead of spooling everything to disk first,
                 // if we don't have any post processing that's required.
                 parallelIteratorFactory = upsertParallelIteratorFactoryToBe = new UpsertingParallelIteratorFactory(connection, tableRef);
+                // If we're in the else, then it's not an aggregate, distinct, limted, or sequence using query,
+                // so we might be able to run it entirely on the server side.
+                runOnServer = sameTable && isAutoCommit && !(table.isImmutableRows() && !table.getIndexes().isEmpty());
             }
             // If we may be able to run on the server, add a hint that favors using the data table
             // if all else is equal.