Вячеслав ЛюбомудровPS. По-последнему запросу ТС очень похоже, что он нас либо троллит, либо что-то слишком скрывает (where 1=1 and t.DATA = sysdate and t.DATA = sysdate - 1)

нет, не тролю, все планы запросов реальны и тексты
последний же вопрос касался, не булкколлекта, а изменения плана при действии со столбцами. я взял запросы из процедуры, подставил вместо биндинга переменноых sysdate, получил план запроса с + t.VREMYA/86400 и без.

1=1 - пишу часто когда отлаживанию, чтобы удобнее было закомментировать первое условие и не убирать анд у второго, часто на автомате добавляю уже. на план не влияет, проверил.
t.DATA = sysdate and t.DATA = sysdate - 1 т.к. проверял сам запрос на время выполнения по дню, топом построил по нему план и планы честно выложил.

вот то что при bulk collect оптимизатор может применять всегда план удобный для ALL_ROWS - согласен.
но не понятно почему
for c in (select ) - работает с "правильным" планом (с первой страницы),
open c for 'select'; или open CURSOR; fetch - работает с "плохим" планом. я не понимаю

barrabasвот то что при bulk collect оптимизатор может применять всегда план удобный для ALL_ROWS - согласен.
но не понятно почему
for c in (select ) - работает с "правильным" планом (с первой страницы),
open c for 'select'; или open CURSOR; fetch - работает с "плохим" планом. я не понимаю
а главное как выяснить какую конструкцию применять для получения правильного плана, я не понял.
мне же в упрек ставили что я попробовал все варианты, а можно было как-то сразу догадаться видимо

но реально ребята помогли.
я переписал древние загрузки (которые лет 10 никто не трогал, но за это время объем данных вырос на пару порядков) с динамического execute immediate 'insert into BUF select ...' на динамеческий open c for 'select '; fetch bulk collect + forall insert

если на 500-700тыс.записей вставка в буфер была по 35-40 минут, теперь 3-4 минуты.