Есть два запроса следующего вида:

SELECT ... FROM view WHERE ....... DOG_ID = :DOG_ID
SELECT ... FROM view WHERE ....... DOG_ID in ( SELECT /*+ NO_UNNEST PUSH_SUBQ */ :DOG_ID FROM DUAL)

Первый - работает быстро, т.к. таблица CH@SEL10 использует индекс по полю DOG_ID
Второй - дебил Oracle заменил подзапрос IN на EXISTS, сначала выполняет View с Full table scan (и другими 100500 условиями), потом фильтрует результат по
EXISTS (SELECT /*+ NO_UNNEST PUSH_SUBQ */ 0 FROM "SYS"."DUAL" "DUAL" WHERE TO_NUMBER(:DOG_ID)=:B1)

Каким хинтом можно попытаться это побороть?

Хинты:
NOREWRITE LEADING( CH@SEL10 ) INDEX( CH@SEL10 ..... )

ноль эффекта ((( Каким хинтом отключить преобразование IN в EXISTS ?

Elic, спасибо за помощь.

Но я ничего не понял ((( Куда можно воткнуть rownum?

p.s.
таблица 51 309 222 записей
стоимость на View в плане запроса показывается 178 975

p.p.s.
перенес подзапрос в WITH секцию с Rownum, понятное дело, те же я@#$, но в профиль (((
Т.к. все равно в WHERE секции пришлось написать
DOG_ID in (SELECT DOG_ID FROM MyWith)
просто View с фильтром сменилось на HASH-JOIN-SEMI с тем же фильтром EXISTS по материализованному WITH

SYПопробуй:
уже так сделал

Но хотелось бы понять по исходному вопросу. Т.к. уже не в первый раз с такой порнографией сталкиваюсь.

Вячеслав ЛюбомудровNO_QUERY_TRANSFORMATION ?
Не помогает
Все равно IN ==> EXISTS

p.s. ну или я не правильно написал хинт (((

Melkomyagkii_newbiNO_MERGE Пробовали?
попробывал... результат тот-же, никакой

"Oracle умный - ему виднее" ( C )

Melkomyagkii_newbi....
Он не всегда работает, тут как раз обсуждали случай с exists
...
прочитал... ну что сказать, печалька
это хорошо, что "не всегда работает", но, бл@#$ как же жить? при таком умном оптимизаторе (((

Melkomyagkii_newbiIN на = поменять, завернуть DOG_ID в max()..

Не понял при чем тут Max. Мне нужен именно IN, реальный подзапрос может вернуть от 1 до 3 записей.

Leonid KudryavtsevSYПопробуй:
уже так сделал
....

Это в PL/SQL девелопере хорошо ((( а в реальной системе - не могу. Я могу только WHERE клаузу править (((
Или новую View в базе создавать и туда пропихивать (((

В общем - кривость.

andrey_anonymousLeonid KudryavtsevWHERE TO_NUMBER (:DOG_ID)=:B1
Не смущает?
Смушает.
Эксплеин план в PL/SQL девелопере. Бинд переменные, разумеется, никто не указывал.

FogelПопробуй PRECOMPUTE_SUBQUERY вместо NO_UNNEST PUSH_SUBQ
все тоже самое

"Oracle умный - ему виднее" ( C )

j2k

отрабатывает по индексу?

Да, по индексу

andrey_anonymousлучше все-таки смотреть за реальными планами посредством dbms_xplan.display_cursor
я и без плана вижу, что все плохо. Т.к. 10 секунд или 15 минут - заметно и без плана (((

с чего реальный план будет хороший, если даже explain plan показывает бред (((

SYLeonid KudryavtsevНо хотелось бы понять по исходному вопросу.

Пропихивание прeдикатов внутрь представления задача сама по себе нетривиальная для оптимизатора. Pipelined (или просто table) функция более тонкий инструмент для этого по сравнению с представлением.

SY.

А как в этом случае будет выглядить where ?
Ну сделаю я pipe-line ф-цию которая возврашает мне 3 ID'ника, но дальше все равно будет

DOG_ID IN (SELECT что-то FROM my_pipe_line_function )

Пока единственное приемлимое для меня решение, просто хардкодить ID'ники в теле запроса макроподстановкой. Oracle сам вынуждает ((( нарушать мантры "нужно использовать bind переменные"