Things SQL needs: MERGE JOIN that would seek

I think it would be better still to, when seeking forward, have it examine a couple of records, then start jumping forward in powers of 2 until it has located an interval with the next value in it, which it then does a binary search on to find the right location.<p>This is at most a factor of 2 less efficient than a binary search, it is fast when the sequential reads are fast, and it doesn't rely on statistics telling the whole story. (For instance the size discrepancy could be explained by a small number of large gaps. This strategy would quickly jump the gaps while still getting fast sequential read behavior elsewhere.)

He's cheating a bit. He created two tables each with 1 million rows, offset by 999,000. (i.e. 1 - 1,000,000 and 999,000 - 1,999,000)<p>Which of course is the best case scenario for this query.<p>But this is very unlikely in the real world. In the real world you use sequential IDs, and almost all the IDs exist. So seek is not useful.<p>If you use random IDs (like using a GUID for a primary key), it's still not useful. If your random number generator is at all good your index numbers are pretty well distributed, without the large gaps this query likes.