2 softbuilder@inbox.ru
если учесть что на девятке выполнялось быстрее, то "также быстро".

2 Denis Popov:
> У меня вопрос: если подобный запрос периодически выполняется, то не
> стоило ли однажды, дождавшись выполнения при максимальном значении
> optimizer_max_permutations, закрепить план выполнения памяти, и в
> дальнейшем использовать его, не строив сызнова?

к сожалению так сделать нельзя. Точнее можно, но такая возможность бывает очень редко. Поясню. Запросы генерятся автоматически на основе метаописаний при помощи рукотворного генератора. При каждом запуске генерится новый SQL с новыми ограничениями. То что этот генератор нуждается в доработке - вопросов нет. Но это пока единственное средство полностью отвечающее требованиям по функциональности (что доминирует над остальными критериями в моей ситуации).

2 DBA
факт. запрос "трехэтажный". дерево планировщика состяло из 154 операций (steps). Вообще речь идет о сокращении времени с 17 минут до 3-х - при первом запуске запроса, и до 45 сек. - при втором и последующем запуске того-же запроса ("кэш в работе").

Скорее всего, второй запуск на выполнение уходит на простую сверку селекта и изменений кэша (+ выдача результата), что составляет ок. 45 сек.

Проблема сокращения времени обработки запроса комплексная. Допускаю что влияли и прочие факторы (изменения которых мы старались избегать). Но то, что время обработки (по крайней мере львиная доля) сократилось из-за изменения обсуждаемого параметра - это бесспорно.

Я говорю про факт.

СУБД рассматриваю как черный ящик.

На входе: запрос SQL, параметры СУБД, версия СУБД, конфигурация аппаратуры.

На выходе: время выполнения.

Оснавная задача: сократить время выполнения.

Примечание: работа кэша особо не интересует. 9-ка приводится только потому, что различия обнаружились лишь прогнав запрос на двух СУБД. Для исключения влияния аппаратных мощностей был проведен тест на одной и той же машине (видно по списку).

Результат: ЗНАЧИТЕЛЬНО сокращено время выполнения запроса SQL, изменив значение параметра optimizer_max_permutations.

На что уходит время мне не интересно.

> ну-ну, рассматривайте и дальше СУБД как черный ящик. Я так понимаю, что и план выполнения вас особо не интересует.

Как раз интересует, но с точки зрения стоимости выполнения запроса. Очевидно что время выполнения запроса с меньшей стоимостью будет выполнено быстрее. Я уж не буду говорить о том что стоимость изменилась после изменения параметра оптимизатора.

2 dba
см выше

тоже неплохо.

К сожалению мое начальство незнает что такое "план выполнения". Оно знает что такое "время".

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

Причем здесь патч (хотя о них я писал выше: тестили с ними и без них)?

Ко второму замечанию: данные кэшируются - однозначно (и во всех тестах). Как запрос может не парситься?

Повторяю. Тесты проводились на различных конфигурациях оборудования (кроме 2-х случаев: см тест 3 и 4) для того чтобы понять как сильно влияет на результат хардверная состаляющая. Прочие условия тестирования поддерживались одинаковыми для всех случаев.

трассировку чего?