Не отбрасываются партиции

Существует партиционированная таблица t1(f1 date, f2 number, f3 number) partition by range (f1)
Определён локальный партиционированный индекс по полям idx1(f1, f2)
Запрос типа

select *
from t1
where f2 = :1
and f1 > :2 and f1 < :3
and f3 = :4

выполняется очень медленно, с удивлением вижу вот такое в плане:

TABLE ACCESS FULL t1 PARTITION: 1 90 (космические цифры стоимостей и байтов)

А хотелось бы PARTITION: KEY KEY
Ну и соответственно elapsed time совсем меня не устраивающий.
С какого перепугу? Индекс не подхватывается.
Думаю, что и без индекса должен пранинг быть. Это так?
Понятно, что некоторое время после добавления новой партиции у меня нет статистики по ней, но это же не повод лезть во все подряд партиции. Что-то я не верю, что дело только в статистике.

ClonCD,

а зачем в локальном индексе у Вас ключ секционирования?

suPPLer,

Пишут (Кайт, например, да и в документации), что такой PREFIXED индекс гарантированно отрежет партиции.
Прошу совета бывалых и уверенно пользующих партиции. У меня опыт небольшой, на 10-ке я ни на какие грабли при партиционировании не наталкивался, а вот на 11.2 первый же опыт привёл к таким результатам.

ClonCD

select * from t1 where f2 = :1 and f1 > :2 and f1 < :3

Скорее всего :2, :3 - не date.
Например, если это timestamp, то будет иметь место неявное преобразование f1 date->timestamp, которое отключит не только индекс, но и пранинг.

ClonCD

suPPLer, Пишут (Кайт, например, да и в документации), что такой PREFIXED индекс гарантированно отрежет партиции.

Если Вас не затруднит, то дайте ссылки на/цитаты из доки и высказывания Тома о подобном.

suPPLer

+ ] ClonCD suPPLer, Пишут (Кайт, например, да и в документации), что такой PREFIXED индекс гарантированно отрежет партиции. Если Вас не затруднит, то дайте ссылки на/цитаты из доки и высказывания Тома о подобном.

В принципе, уже и сам нашёл. Вам стоит читать стоит внимательнее:

Thomas Kyte "Expert One-on-One Oracle", Ch.14

В документации Oracle подчеркивается, что: локально фрагментированные индексы с префиксом обеспечивают более высокую производительность, чем индексы без префикса, потому что уменьшают количество проверяемых оптимизатором индексов Понимать это надо так: локально фрагментированные индексы обеспечивают более высокую производительность для ЗАПРОСОВ, ссылающихся на весь входящий в них ключ фрагментации, по сравнению с ЗАПРОСАМИ, не ссылающимися на ключ фрагментации

И дальше пример, когда оптимизатор не смог откинуть отключённую секцию, используя непрефиксный локальный индекс для запроса без фильтра по ключу секционирования. В Вашем запросе фильтр по ключу секционирования есть. ;)

suPPLer

В Вашем запросе фильтр по ключу секционирования есть. ;)

Нету у него фильтра.
И индекс не подцепился по той же причине, по которой не сработал pruning.
По крайней мере это верно, если приведенный план соответствует действительности.
Могу продемонстрировать как это не работает на подобном запросе.
Впрочем, Вы и сами можете ;)

andrey_anonymous,

Бинго! Именно такое неявное преобразование! Спасибо большое!

А по поводу Кайта - 3-е изд. стр.126
"Главное - проверить есть ли в запросах условия, позволяющие игнорировать секции таблицы. При использовании локально секционированных индексов с префиксом это гарантируется."

andrey_anonymous

suPPLer В Вашем запросе фильтр по ключу секционирования есть. ;) Нету у него фильтра.

В запросе - есть. В плане выполнения - нету. Я, наверно, не слишком ясно выразился, для меня фильтр в запросе - это условие в инструкции WHERE. Ну а TIMESTAMP вместо DATE в переменных - это уже, как Вы и сказали, причина, по которой "не взлетело" откидывание лишних секций и использование индекса. Мне просто была интересна аргументация для использования префиксного индекса у ТС.

ClonCD,

там на самом деле сказано намного больше, в этом заключительном абзаце. ;)