Всем доброго времени суток.

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



при использовании DBMS_SQL мой код выполняется примерно 15с, причём если использовать execute immediate c using'ом,
то запрос отрабатывает быстро ~3c. Причём заметил следующее если убрать второе условие или заменить его на


то запрос отрабатывает быстро, но если в условии появляется OR, то беда.

Я так понимаю, что 15с. это полный перебор всех значений в столбцах, т.е. условие ДК.DOPER = TO_DATE(:P3_DATE, 'DD.MM.YYYY'),
не применяется. Почему это происходит я понять не могу.

У кого есть идеи по данному поводу?

123ййmrsergejAND (ДК.CLI_CODE LIKE '%' || :P3_CLI_CODE || '%')
а вы уверенны, что вам такое надо при условии
ДК.CLI_CODE=12345678
:P3_CLI_CODE=5
?

Не очень понял, честно говоря о чём был вопрос.

У кого какие идеи? Очень странно, что запрос ведёт себя таким образом именно при использовании DBMS_SQL.
Хотя бы подскажите в какую сторону нужно копать.

ElicmrsergejЯ так понимаю, что 15с. это полныйТо есть ты не в состоянии посмотреть актуальные планы выполнения?

15с это полный перебор.
Т.к. таблица inmemory, то в плане всегда присутствует TABLE ACCESS INMEMORY FULL (план всегда одинаковый), но при выполнении
запроса просто в sql окне или через execute immediate с секцией using запрос отрабатывает быстро.

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


использовать


или

Может есть ещё идеи в какую сторону копать?

MaximaXXLmrsergejМожет есть ещё идеи в какую сторону копать?

Копайте в сторону Австралии

и вообще задумайтесь в чем сокральный смысл такой конструкции



если при :P3_CLI_CODE = null выберутся все значения по условию :P3_CLI_CODE IS NULL и по условию ДК.CLI_CODE LIKE '%' || null || '%'

Я сейчас только для Вас открою тайну, можете записать куда-нибудь, чтобы не забыть - при значении :P3_CLI_CODE = null второе условие проверяться даже и не будет

Leonid KudryavtsevIMHO & AFAIK 1
Может выполнятся и не будет, но план портить вполне может....
(т.к. оптимизитор в момент парсинга об этом факте может и не знать)

IMHO 2
Ну и вообще, если есть разница в выполнении. то первым делом желательно сравнить планы.

У меня тоже складывается ощущение, что когда оптимизатор на момент парсинга понимает результат в левой части условия
(:P3_CLI_CODE IS NULL OR ДК.CLI_CODE LIKE '%' || :P3_CLI_CODE || '%'),
то и результат я получаю тот, который ожидаю, но при использовании переменных он не знает, что там будет - истина или ложь и
как его заставить использовать обязательное условие (ДК.DOPER = TO_DATE(:P3_DATE, 'DD.MM.YYYY')) при таком варианте не понятно.

По поводу планов, я не большой спец в инмемори таблицах, но у меня всегда при использовании этой таблицы одинаковый план.
Я не понимаю, почему обязательное условие ДК.DOPER = TO_DATE(:P3_DATE, 'DD.MM.YYYY') применяется не всегда.