This change is 

This was a Friday experiment to see if there were any unexpected complexities. For CRDB, we could set TablePartitioner to something like:

opts.TablePartitioner = func(lastKey, curKey []byte) bool {
	return keys.IsLocal(roachpb.Key(lastKey)) != keys.IsLocal(roachpb.Key(curKey))
}

Turns out there is an unexpected complexity: naively partitioning L0 sstables during flushing creates sstables which overlap in their smallest/largest seqnum, violating the invariants checked by manifest.CheckOrdering. This can be fixed, but doing so will make Pebble incompatible with RocksDB.

In order to make this "real", there is additional plumbing of partitioning that would be required. So the PR message above.

Cc @dt, @miretskiy

Turns out there is an unexpected complexity: naively partitioning L0 sstables during flushing creates sstables which overlap in their smallest/largest seqnum, violating the invariants checked by manifest.CheckOrdering. This can be fixed, but doing so will make Pebble incompatible with RocksDB.

I took another look at RocksDB's invariants this morning. It simply checks that the L0 files are "sorted properly". The sorted properly check uses the same comparator that it uses for sorting itself (i.e. sort by largest seqnum). The result is that all RocksDB is checking for in L0 is that std::sort works and that the L0 comparator is stable. This is good news. I think we can partition L0 sstables in Pebble and still remain compatible with RocksDB.