Currently, we only replace an OR_STAGE with a MERGE_SORT_STAGE when the sort order of the underlying indexes are shared and match the desired sort order of the query.

The OR_STAGE uses unbounded memory to de-duplicate records. The MERGE_SORT_STAGE currently seems to do the same, but could be optimized to use far less memory than the OR_STAGE since duplicate records are coming in from child stages in the same order.

Given that MERGE_SORT_STAGE can be optimized to avoid unbounded memory, we should consider aggressively using it instead of OR_STAGEs, and re-SORTing afterwards (which happens in the OR_STAGE case as well).