anchor.diff:      {X,Y,Z,Index};
   find_quantum_field_index_in_key2([_|Tail], Index) ->
       find_quantum_field_index_in_key2(Tail, Index+1).
  -
  -%%
  -fix_start_order(W, Mod, LK) ->
  -    {startkey, StartKey0} = lists:keyfind(startkey, 1, W),
  -    {endkey, EndKey0} = lists:keyfind(endkey, 1, W),
  -    StartVals = [{N, V} || {N, _T, V} <- StartKey0],
  -    EndVals = [{N, V} || {N, _T, V} <- EndKey0],
  -    StartKey = riak_ql_ddl:make_key(Mod, LK,  StartVals),
  -    EndKey = riak_ql_ddl:make_key(Mod, LK,  EndVals),
  -    case StartKey < EndKey of
  -        true ->
  -            W;
  -        false ->
  -            %% Swap the start/end keys so that the backends will
  -            %% scan over them correctly.  Likely cause is a descending
  -            %% timestamp field.
  -            W1 = lists:keystore(startkey, 1, W, {startkey, EndKey0}),
  -            W2 = lists:keystore(endkey, 1, W1, {endkey, StartKey0}),
  -            %% start inclusive defaults true, end inclusive defaults false
  -            W3 = lists:keystore(start_inclusive, 1, W2,
  -                                {start_inclusive, proplists:get_value(end_inclusive, W, false)}),
  -            _W4 = lists:keystore(end_inclusive, 1, W3,
  -                                 {end_inclusive, proplists:get_value(start_inclusive, W2, true)})
  -    end.
  -
  -%% Make the subqueries appear in the same order as the keys.  The qry worker
  -%% returns the results to the client in the order of the subqueries, so
  -%% if timestamp is descending for equality queries on family/series then
  -%% the results need to merge in the reverse order.
  -%%
  -%% Detect this by the implict order of the start/end keys.  Should be
  -%% refactored to explicitly understand key order at some future point.
  -fix_subquery_order_compare(Qa, Qb) ->
  -    {startkey, Astartkey} = lists:keyfind(startkey, 1, Qa?SQL_SELECT.'WHERE'),
  -    {endkey, Aendkey} = lists:keyfind(endkey, 1, Qa?SQL_SELECT.'WHERE'),
  -    {startkey, Bstartkey} = lists:keyfind(startkey, 1, Qb?SQL_SELECT.'WHERE'),
  -    case Astartkey < Aendkey of
  -        true ->
  -            Astartkey =< Bstartkey;
  -        false ->
  -            Bstartkey =< Astartkey
  -    end.
  -
  -fix_subquery_order(Qs) ->
  -    lists:sort(fun fix_subquery_order_compare/2, Qs).
   
   hash_timestamp_to_quanta(QField, QSize, QUnit, QIndex, MaxSubQueries, Where1) ->
       GetMaxMinFun = fun({startkey, List}, {_S, E}) ->
  
positive.code:     %% now make the result - expecting 2 queries
      [Where1, Where2] =
          test_data_where_clause(<<"Scotland">>, <<"user_1">>, [{3000, 15000}, {15000, 30000}]),
      PK = get_standard_pk(),
      LK = get_standard_lk(),
      ?assertMatch(
         {ok, [?SQL_SELECT{ 'WHERE'       = Where1,
                            partition_key = PK,
                            local_key     = LK},
               ?SQL_SELECT{ 'WHERE'       = Where2,
                            partition_key = PK,
                            local_key     = LK
                          }]},
         compile(DDL, Q, 5)
        ).
  
  %%
  %% test failures
  
negative.code:         "PRIMARY KEY  ((a,b), a,b))"),
      {ok, Q} = get_query(
            "SELECT * FROM tab1 WHERE a = 1 AND b = 1"),
      {ok, [?SQL_SELECT{ 'WHERE' = Where }]} = compile(DDL, Q, 100),
      ?assertEqual(
          [{startkey,[{<<"a">>,timestamp,1},{<<"b">>,varchar,1}]},
           {endkey,  [{<<"a">>,timestamp,1},{<<"b">>,varchar,1}]},
           {filter,[]},
           {end_inclusive,true}],
          Where
      ).
  
  %% partition and local key are different
  