Собственно, интересует именно ТЕКУЩИЙ, который есть в неудобоваримом виде в sysprocplan. Интересует, поскольку нет уверенности, что создав в EXPLAIN ON такую же ХП с другим именем или выполнив UPD STAT PROC, информикс не сформирует план отличный от бывшего... Или опасения напрасны?

Да, сорри, IDS 7.31 UD8, IDS 9.40 UC8...

Александр СпиринВозможно, Вам поможет syssqexplain в sysmaster'е?
Это вряд-ли: имеющаяся информация в syssqexplain настолько скудна, что даже при запросе из одной таблицы скажет вам, к примеру, что индекс использовался, но какой КОНКРЕТНО... :(
Что уж говорить о запросе к нескольким таблицам...

Александр Спирин
Одновременно, есть шансы, что план запроса всё же не изменится при перекомпиляции , если не было существенных изменений.

" Есть шансы" в то время, когда приходится грызть оптимизацию - очень стрёмно :)

Александр Спирин
Всё же оптимизатор меняет план запроса не из-за самих изменений, а если находится более дешевый способ его исполнения...

Вот-вот, в том-то и проблема...
Есть случаи, когда оптимизатор меняет план запроса, но отнюдь не на более "дешёвый"...

Привожу пример из жизни:
п.1) таблица с одним "сильно разбалансированный" индексом №1 - то есть минимальное количество записей на один ключ и максимальное количество записей на один ключ ОЧЕНЬ сильно отличаются, а AVG этого количества сильно смещено в сторону MIN (надеюсь, выразился понятно, хотя может и своеобразно)
п.2) имеем хранимые процедуры с запросами, использующими переменные. Оптимизатор использовал индекс №1
п.3) имеем тысячу вызовов разных ХП (совершенно условно назовём OLTP) с параметрами, кторые очень эффективно обрабатываются при использовании индекса №1 и десяток вызовов других ХП (совершенно условно назовём DSS), которые очень не эффективно обрабатываются при использовании индекса №1
п.4) с целью улучшения DSS добавляем второй "сильно разбалансированный" индекс №2, при использовании которого вызовы DSS должны обрабатываться гораздо эфективнее
п.5) обновляем статистику по таблице и ХП
п.6) информикс решает использовать в запросах ХП индекс №2.
п.6) получаем расклад, при котором DSS запросы сами по себе начали работать быстрее, а вот OLTP - просто таки насилует систему...

Вариант "А не пересмотреть ли реализацию или тем паче архитектуру?!" предлагаю не рассматривать в силу разных причин: трудозатратности, специфики сопровождения системы, точки зрения хорошего (с моей точки зрения :) администратора (всем вышеперечисленным стоит заниматься, если мои трудозатраты на достижение требуемого результата превысят 20% от трудозатрат на смену реализации/архитектуры)

Так вот, приведённый пример кажется простым и понятным, когда он разложен по полочкам. А как вести себя разработчику/администратору в большой системе, чтобы ответить на вопрос: "А что изменится в оптимизации тысячи ХП, если я добавлю ещё один не бесполезный, IMHO, индекс?"

Для того чтобы понять, что оптимизатор нашёл НОВЫЙ способ, вижу только три пути:
1) запросы до и после изменений отличаются по "скорости" выполнения - как видим по примеру, шишкоёмкий (с) способ
2) оптимизатор показал в sqexplain разную оптимизацию - для этого можно, например, сознательно включать и хранить историю expain при очередном обновлении статистики (хотя что делать с запросами, использующими временные таблицы, остаётся непонятным), а потом сравнивать (тоже отдельная песня :)
3) таки надеяться найти нужное в sysmaster :)

Ещё варианты или уточнения к предложенным вариантам есть? :)

сильно порезано GVF112GVF
1. OLCP (OLTP+DSS) - режим - новый релиз INFORMIX - 11.x
2. IDS 10.x - внешние директивы
3 два сервера INFORMIX

С уважением,
Вадим.

Согласен - тоже варианты...

Журавлев Денис АнатоЛойп.5) обновляем статистику по таблице и ХП
п.6) информикс решает использовать в запросах ХП индекс №2.Т.е. теже oltp запросы без хр.п, по прежнему выбирают первый индекс?

Да (т.е. запросы с константами вместо переменных выбирают индекс №1.

Судя по всему, приятный выбор обеспечивает информация о распределении ключей...

Журавлев Денис
Это редкий случай в часто встречающихся ненормализованных системах.
"Ненормализованных" - в каком контексте в данном случае? С учётом известных нам нормальных форм...

Простой пример (если с планом бухсчетов знакомы): Бухгалтерские проводки с аналитикой плана счетов в одной таблице. Пример таблицы для простоты:
В зависимости от счета, ид "Работник ДТ" и "Работник КТ" може быть NULL.

Имеем:
1) 2НФ - не соответствие 3НФ ("Работник ..." зависит не только от первичного ключа, но и частично от "Счёт..." - для большинства проводок (счетов) аналитики по работнику нет...)
2) "дисбаланс" индексов, использующих поля "Работник ..."

Стоит подумать, нормализация до 3НФ (выделение таблицы
или даже
) откликнется ли БОЛЬШЕЙ пользой как при выполнении типичных запросов с использованием фильтров по счетам, дате и работникам, так и по изменению данных... Не забываем, что речь идёт о запросах в ХП, и запросы используют фильтры-переменные...

onstat-Попробуйте пересобрать статистику 2 раза подряд
сначала с опцией drop destributions потом без.
Мне несколько раз выручало в подобного рода случаях.
Прямо сейчас не могу - но позже попробую и расскажу...