# `MergeJoin` Operator - Cont'd

![`smart`](MergeJoin05_aa_001_20230913.png)

------------------------------------------------------------------------------
For the next row in `employees` (e.g., `emp_no = 10002`), only the subsequent row in the `salaries` table needs to be checked, rather than starting from the beginning. This approach efficiently completes the `MergeJoin` algorithm.

Note that the `MergeJoin` operation, which compares rows in ascending order, does not support parallel processing. Additionally, it requires both tables to be stored in sorted order in the cache, resulting in higher cache requirements. Due to these constraints, the optimizer may not favor `MergeJoin` unless the scenario is highly suitable. Next, we'll examine how `MergeJoin` appears in the SQL execution plan and explore how to make the optimizer more likely to use this join method.