Здравствуйте, LaPerouse, Вы писали:

LP>Вообще, самый стандартный случай долгого выполнения запроса — это когда несколько джоинов, и для них выбирается не тот план. Не верю, что у тебя не было таких случаев — это вообще очень распространенная проблема, каждый разработчик хотя бы раз, да сталкивался с этим.

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

Момент прикольный сам по себе, согласен, но он не зависит от того, статически ли составляется список планов или его перебирают динамически.


V>>- для исторических данных не надо много динамических планов, бо данные неизменяемые, индексы априори пересчитаны, как я предлагал т.н. "профилирование по реальным данным" — оно вполне может быть частью операции "закрытие периода" — это одна из самых важных операций ЛЮБЫХ учётных систем более-менее серьезного уровня.
LP>Индексы пересчитаны, но они огромные, и условия могут меняться.

Огромные или нет индексы — не принципиально.
Я предлагал статически генерить следующее:
— код, оценивающий некий план;
— код. исполняющий этот план.

Суть предложения в том, что в обеих процедурах высокое повторное использование кода с другими запросами вокруг одних и тех же таблиц.

Например:

float calcWeght_ScanByIndex_Table1_Index1(int value);

Эта процедура повторно используется (вызывается) из многих процедур оценки планов, где план подразумевает выборку из Table1 через Index1.

Еще:

float calcWeght_ScanByIndex_Table1_Index2_Range(DateTime minValue, DateTime maxValue);

Думаю, смысл понятен.

В любом случае всё мн-во планов для реальных запросов базой генерится. Просто не в момент компиляции, а в момент работы.
Если этих планов совсем уж много — их можно разбить на подгружаемые модули. Модули в С++, в отличие от дотнета, можно загружать и выгружать динамически, т.е. вполне можно содержать тоже некий кеш планов, просто не динамически сгенерённых, а статически.

Здравствуйте, LaPerouse, Вы писали:

LP>Вообще, самый стандартный случай долгого выполнения запроса — это когда несколько джоинов, и для них выбирается не тот план. Не верю, что у тебя не было таких случаев — это вообще очень распространенная проблема, каждый разработчик хотя бы раз, да сталкивался с этим.

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

Момент прикольный сам по себе, согласен, но он не зависит от того, статически ли составляется список планов или его перебирают динамически.


V>>- для исторических данных не надо много динамических планов, бо данные неизменяемые, индексы априори пересчитаны, как я предлагал т.н. "профилирование по реальным данным" — оно вполне может быть частью операции "закрытие периода" — это одна из самых важных операций ЛЮБЫХ учётных систем более-менее серьезного уровня.
LP>Индексы пересчитаны, но они огромные, и условия могут меняться.

Огромные или нет индексы — не принципиально.
Я предлагал статически генерить следующее:
— код, оценивающий некий план;
— код. исполняющий этот план.

Суть предложения в том, что в обеих процедурах высокое повторное использование кода с другими запросами вокруг одних и тех же таблиц.

Например:

float calcWeght_ScanByIndex_Table1_Index1(int value);

Эта процедура повторно используется (вызывается) из многих процедур оценки планов, где план подразумевает выборку из Table1 через Index1.

Еще:

float calcWeght_ScanByIndex_Table1_Index2_Range(DateTime minValue, DateTime maxValue);

Думаю, смысл понятен.

В любом случае всё мн-во планов для реальных запросов базой сегодня генерится. Просто не в момент компиляции, а в момент работы.
Если этих планов совсем уж много — их можно разбить на подгружаемые модули. Модули в С++, в отличие от дотнета, можно загружать и выгружать динамически, т.е. вполне можно содержать тоже некий кеш планов, просто не динамически сгенерённых, а статически.