1. Есть вью вида:


2. каждая таблица этой вью имеет миллионы записей и индекс по ключевому полю возвращающий для каждого значения одну запись, т.е. практически уникальный

3. запрос к view вида


дает план с обращением по индексу к каждой таблице view и отрабатывает за доли сек.

4. а вот запрос вида


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

При этом если задать id явно


То индекс вьюшных таблиц снова подхватывается. А через соединение нет.

гистограммав запросе.
можно продолжить -> в разработчике -> обществе -> пространстве -> ничего не поделаешь, так устроен мир )
А что там с гистограммами? Может все на поверхности и как-то обойтись без этого страшного слова? :)

ORA__SQL , спасибо помогло, все-то ему подсказывать надо оказывается ) еще и знать как подсказать )

orawish , просто не понял как можно построить такой план, что при живом индексе, по которому достается одна запись для значения начинать лопатить миллионные таблицы. Статистика собрана. То есть каков механизм, что оракле посчитал, что самое зашибись будет, если начать жеско колбасить диски, а индексы это все фигня )
Когда хинтом протолкнули предикат внутрь вью (раньше не приходилось сталкиваться), все заработало. При этом именно при объединении теряет, при запросе по конкретному значению- то нормально ж все.

xtenderтрассу 10053 покажите
Нет у меня доступа к совершению таких чудес )
xtenderЧасто такая бяка бывает из-за устаревшей или отсутствующей статистики на одной из таблиц/индексов
Ок. Дропаю индекс на одной из таблиц - при запросе по параметру по ней будет фулскан, а по остальным ищет по индексу.
То есть налицо, что оракл смотрит дифференцировано на каждую таблицу вью и принимает решение отдельно по каждой. И это ожидаемо. Так? Теперь строим снова такой же индекс (свежий же). И картина повторяется - по параметру индекс подхватывается, а при соединении вью с другой таблицей начинает фулсканить (сейчас кстати начал IFFS).
Но ладно, без трассировки видно все равно не понять, потому все это лирика у меня - пусть будет PUSH_PRED.
Версия 11.2.0.1.0 EE