К обсуждению изобретение нового велосипеда с ракетным двигателем.
Подходящего форума не подобрал

Оптимизатор SQL-запросов, основанный на нейронной сети

Основные постулаты:

- CBO требует константного обновления статистики, иногда очень долго выбирает план
- эвристика типа RBO не угадывает правильный порядок
- большинство запросов в продакшн-системах повторяются и их набор конечен

Недостатки нового подхода:
-Исторические подходы стабильны: CBO уже доказал свою устойчивость, также есть его усиление генетическими алгоритмами в Postgres
-при обучении нейросети возникнет доп.нагрузка на сервер, также на время обучения оптимизация должна проводится проверенными методами
-при относительно простых запросах (менее десятка соединений) выгода подхода относительно стандартных способов может быть малой

Организация нейронной сети
1. Элементом нейронной сети является простая операция запроса, включая параметры и текущие условия на сервере. Элементы имеют взаимные связи.
2. Весом элемента является время выполнения операции (альтернативно оценка CBO или RBO).
3. Запрос, таким образом представляет собой дерево N элементов плюс M параметров. Простые условия уменьшают размерность многомерного пространства сети (максимум M+N).
4. Требуется решить с помощью нейросети «задачу коммивояжера».

Идеи реализации
1. Базовый (Rule-based или Cost-based) оптимизатор отсеивает очевидные вещи и оставляет набор планов запросов для проверки.
2. Ведется статистика выполнения запросов – оптимизировать нужно или часто выполняемые, или указанные вручную.
3. Тестовые или проверочные запросы могут выполняться не в ядре СУБД, а внешней утилитой.
4. Записываем результат выполнения тестовых запросов в конкретных условиях – количество коннектов, занятость памяти, количество выполняемых запросов.
5. Update не воспроизведешь – но их количество мало и они проще.
6. При явном преимуществе нового плана выполнения – выдаем хинт.
7. Следует учесть, что при различных условиях или ! при разных параметрах запроса преимущества могут иметь разные планы.

Поскольку идеи могут мне же в будущем пригодиться, например продам инвесторам в Сколково, авторское право застолблю за собой =)
P.S. Так как основная идея состоит в разбиении сложного запроса на атомарные части и их группировке и обучении сети частиц, алгоритм с полным правом может называться НАНООПТИМИЗАТОРОМ SQL-запросов .

Gluk (Kazan)1 апреля вроде прошло?
или я за календарем не следил???В этой области уже имеется:
-United States Patent 6108648
-масса научных работ (гуглится)

Gluk (Kazan), конечно ты помнишь про Oracle ADDM =)

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

Кроме того - ничего не мешает мониторинг и анализ вести на отдельном сервере.

Нейросеть и предназначена для выбора решения при неполных входных данных.

Решение не обязано быть идеальным и единственным (поиск идеала может уйти в бесконечность).
Только при правильном построении выбор сети должен стремиться к хорошему решению.

Потому хранить бесконечный набор входных данных тоже необязательно.

Пока нейросеть не обучена, нужно использовать старые привычные оптимизаторы.
А пробы вариантов предлагается проводить в фоне - отдельными задачами.

interesting, ты перевозбудился ))

Во-первых, это только идея, а не ответ поисков Святого Грааля.

Во-вторых, сравнивать детерминированные алгоритмы (NP- итд) с и алг.с нечеткой логикой неправильно.

В-третьих, еще ничего не даже не опробовано, а ты уже знаешь ответ (про локальные экстремумы итд)!? )))))