IN-List итератор с уникальным индексом

Читаю доку по оптимизации и наткнулся на следующее:

Example 2–3 uses a unique index. Because there is a sort involved on the IN-list, even with complete keys of unique indexes, there is still a range scan.

Example 2–3   IN-List Iterator with Unique Index
SELECT header_id, line_id, revenue_amount
  FROM so_lines_all
 WHERE line_id IN (1011,1012,1013);
Plan
-------------------------------------------------
SELECT STATEMENT
 INLIST ITERATOR
  TABLE ACCESS BY INDEX ROWID SO_LINES_ALL
   INDEX RANGE SCAN SO_LINES_U1

Не совсем точно понимаю причину (механизм) использования сканирования по диапазону в данном случае. Помогите разобраться.

А что тут непонятного? Сканирует индекс от 1011 до 1013 и фильтрует результат.
Inlist iterator говорит о том, что разделы для сканирования локального индекса были отобраны с максимально возможной аккуратностью.

Т.е. сначала значения в IN-списке сортируются, определяется мин. и макс. элемент и в этом диапазоне сканируется индекс. Я вас правильно понял?

Андрей В. Морозов

Т.е. сначала значения в IN-списке сортируются, определяется мин. и макс. элемент и в этом диапазоне сканируется индекс. Я вас правильно понял?

Да работает то он как и заявлено в документации - перебирает по одному все значения в in(). Что касается range - идей нет. Могу только сказать что в 10-ке в случае с уникальным индексом будет INDEX UNIQUE SCAN.

wurdu

Андрей В. Морозов Т.е. сначала значения в IN-списке сортируются, определяется мин. и макс. элемент и в этом диапазоне сканируется индекс. Я вас правильно понял? Да работает то он как и заявлено в документации - перебирает по одному все значения в in(). Что касается range - идей нет. Могу только сказать что в 10-ке в случае с уникальным индексом будет INDEX UNIQUE SCAN.

В 10.2.0.4 у меня по уникальному индексу (первичный ключ) - INDEX RANGE SCAN.

Андрей В. Морозов

wurdu Андрей В. Морозов Т.е. сначала значения в IN-списке сортируются, определяется мин. и макс. элемент и в этом диапазоне сканируется индекс. Я вас правильно понял? Да работает то он как и заявлено в документации - перебирает по одному все значения в in(). Что касается range - идей нет. Могу только сказать что в 10-ке в случае с уникальным индексом будет INDEX UNIQUE SCAN. В 10.2.0.4 у меня по уникальному индексу (первичный ключ) - INDEX RANGE SCAN.

create table i_tst as select rownum rn, 1 name from dual connect by level <= 100000;

Table created.

create unique index idx_rn on i_tst (rn);

Index created.

set autotrace traceonly explain

select * from i_tst where rn in (1,2,3);

Execution Plan
----------------------------------------------------------
Plan hash value: 2577821624

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     3 |    21 |     5   (0)| 00:00:01 |
|   1 |  INLIST ITERATOR             |        |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| I_TST  |     3 |    21 |     5   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | IDX_RN |     3 |       |     4   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

3 - access("RN"=1 OR "RN"=2 OR "RN"=3)

compatibility в 10.2?

У меня compatible=10.2.0.4, optimizer_features_enable=10.2.0.4

Спасибо!