This will simplify the sorting code considerably. Also, we can use AddMutation instead of MutateOverNetwork, which is simpler and faster. Another big advantage is that for RAFT, it is a lot simpler and cleaner if we move the predicate data and index data together.
Why we might want to support index being on a different machine from the predicate data? Why would users want that?
Maybe the user uses the index data much more often than the predicate data. However, even in this case, you won’t lose that much. If you order / sort results, you would need to get the predicate data anyway for the “fine sorting”.
Maybe the user uses the index data much less often than the predicate data. However, it doesn’t sound like you will lose that much as indexing data should be smaller than predicate data (due to delta encoding of keys).
Maybe we like to combine indices of multiple predicates. But this can be easily circumvented by making the query slightly more complex with ORs and ANDs.
Unless there’s any objections (@minions), I am going to go ahead and create a new PR to do sorting with this assumption. I will address comments in the current PR if they are relevant to the new PR. And I will keep the current PR lying around in case we want to use or adapt it further down the road.