AlexFF__|Pavel_PV,
У тебя в каждой партиции может быть до 86400 различных значений, а ты запрашиваешь только одно.
Что тут удивительного?
Попробуй гистограммы собрать.
Дата транкейчена т.е. по факту 1 различное значение в каждой партиции. Плюс из плана видно, что оракл вполне себе корректно определяет кол-во извлекаемых строк. Гистограммы собирать пробовал, у меня не помогло ).
kinky cat , да извращение ещё. Но не поверишь нужно иногда, "bitmap and" отлично работает с этой штукой. Да вопрос больше не в том почему оптимизатор этого сам не видит, а в том что он вместо cost-а рисует какую-то басню. Он реально думает что достанет 200К строк, а cost рисует как будто их там десятки будут. Ниже пример приведу который нагляднее отразит ситуацию.
Так сказать раз там ничего удивительного, давай вот такой пример.
Создаем табличку так же как писал выше. Далее заполняем 4 партиции:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
declare
vDate date;
BEGIN
FOR i IN 1..100000
LOOP
vDate:= date '2017-07-14';
insert into T1(D1,N) select vDate, i from dual;
END LOOP;
commit;
--
FOR i IN 1..4
LOOP
vDate:= date '2017-07-14' + i;
insert/*+ ENABLE_PARALLEL_DML PARALLEL(8)*/ into T1(D1,N) select vDate, N from T1 where T1.D1 = date '2017-07-14';
commit;
END LOOP;
END
/
Собираем статистику и смотрим план вот так, явно укажем хинтом идти по индексу чтобы отследить изменения cost-а:
1.
2.
3.
4.
5.
6.
explain plan for
select/*+ index(T test_index1)*/ *
from T1 T
where D1 >= TO_DATE('14072017','DDMMYYYY')
and D1 <=TO_DATE('15072017','DDMMYYYY');
select * from table(dbms_xplan.display);
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Plan hash value: 890932065
--------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 200K| 2539K| 923 (1)| 00:00:01 | | |
| 1 | PARTITION RANGE ITERATOR | | 200K| 2539K| 923 (1)| 00:00:01 | 15 | 16 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| T1 | 200K| 2539K| 923 (1)| 00:00:01 | 15 | 16 |
| 3 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 4 | BITMAP INDEX RANGE SCAN | TEST_INDEX1 | | | | | 15 | 16 |
--------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("D1">=TO_DATE(' 2017-07-14 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "D1"<=TO_DATE(' 2017-07-15
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
Note
-----
- automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold
Cost = 923, видно что Pstart 15 и Pstop 16.
Теперь добавим в таблицу ещё одну партицию:
1.
insert/*+ ENABLE_PARALLEL_DML PARALLEL(8)*/ into T1(D1,N) select date '2017-07-19', N from T1 where T1.D1 = date '2017-07-14';
Эти данные никак не влияют на верхний запрос с точки зрения информации, у нас ведь указана дата партицирования и просмотр индексов идёт только в партициях этой даты. Собираем статистику по таблице и по индексу. Ещё раз, по идее эти данные никак не влияют на верхний запрос верно? Проверим и получим такой план:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Plan hash value: 890932065
--------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 200K| 2539K| 813 (1)| 00:00:01 | | |
| 1 | PARTITION RANGE ITERATOR | | 200K| 2539K| 813 (1)| 00:00:01 | 15 | 16 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| T1 | 200K| 2539K| 813 (1)| 00:00:01 | 15 | 16 |
| 3 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 4 | BITMAP INDEX RANGE SCAN | TEST_INDEX1 | | | | | 15 | 16 |
--------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("D1">=TO_DATE(' 2017-07-14 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "D1"<=TO_DATE(' 2017-07-15
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
Note
-----
- automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold
Вроде бы всё так, но cost стал меньше. А так всё то же, партиции теже, строк столько же и байт столько же.
Ну давайте ещё одну партицию добавим:
1.
insert/*+ ENABLE_PARALLEL_DML PARALLEL(8)*/ into T1(D1,N) select date '2017-07-20', N from T1 where T1.D1 = date '2017-07-14';
Смотрим план:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Plan hash value: 890932065
--------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 200K| 2539K| 734 (1)| 00:00:01 | | |
| 1 | PARTITION RANGE ITERATOR | | 200K| 2539K| 734 (1)| 00:00:01 | 15 | 16 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| T1 | 200K| 2539K| 734 (1)| 00:00:01 | 15 | 16 |
| 3 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 4 | BITMAP INDEX RANGE SCAN | TEST_INDEX1 | | | | | 15 | 16 |
--------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("D1">=TO_DATE(' 2017-07-14 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "D1"<=TO_DATE(' 2017-07-15
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
Note
-----
- automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold
При этом всё я следил за изменением cost при фуллскане, первый раз он был 334, потом 335 и потом 336. Т.е. никак не падает, действительно с чего бы ему падать? А cost в данном случае постоянно уменьшается, в один момент он становится меньше чем у full scan и появляется картина которую мы наблюдаем в первом моей сообщении.
