Почему Oracle выполняет как TABLE SCAN, так и INDEX UNIQUE SCAN для одной и той же таблицы в одном запросе?

Я не ищу оптимизацию следующего, просто объяснение. У меня есть этот запрос:

SELECT COUNT(LARGE_A.id_a), SUM(LARGE_A.b_integer)
FROM LARGE_A
INNER JOIN MEDIUM_A ON LARGE_A.id_a = MEDIUM_A.id
INNER JOIN MEDIUM_B ON LARGE_A.id_b = MEDIUM_B.id
WHERE
    MEDIUM_A.a_varchar2 LIKE 'Example%' AND
    EXTRACT(YEAR FROM MEDIUM_B.a_datetime) = 2000 AND
    LARGE_A.a_integer BETWEEN 0 AND 1000;

Типы атрибутов записываются в их именах. Идентификаторы являются целыми числами. В таблице LARGE_A 1 000 000 строк, в средних по 100 000. Идентификаторы являются первичными ключами, однако таблица LARGE_A имеет составной ключ (id_a, id_b).

Затем у меня есть следующий план выполнения, взятый из представления V$SQL, потому что Autotrace лжет об этом.

SELECT STATEMENT                        
|SORT AGGREGATE                         
||HASH JOIN                             
|||NESTED LOOPS                         
||||NESTED LOOPS                        
|||||STATISTICS COLLECTOR               
||||||NESTED LOOPS                      
|||||||TABLE ACCESS FULL                LARGE_A
|||||||TABLE ACCESS BY INDEX ROWID      MEDIUM_A
||||||||INDEX UNIQUE SCAN               PK(MEDIUM_A)
|||||INDEX UNIQUE SCAN                  PK(MEDIUM_B)
||||TABLE ACCESS BY INDEX ROWID         MEDIUM_B
|||TABLE ACCESS FULL                    MEDIUM_B

PK означает некластеризованный индекс по первичному ключу (целому числу) таблицы, указанной в скобках. Я не использую IOTs здесь.

Зачем оптимизатору сначала запрашивать записи из индекса одну за другой PK(MEDIUM_B), затем извлекать остальные строки, используя ROWID, а затем снова запускать ПОЛНОЕ сканирование таблицы?