Есть запроса вида


Каждый селект по отдельности выполняется от 1-5 секунд, все вместе выполняются в районе минуты (это долго)
Можно ли распараллелить запрос, разбив на части именно по union all-ам (в надежде, что будет немного быстрее)?

Leonid KudryavtsevНе факт, что параллельно будет в N-раз быстрее. Если все "стоит колом" на обращение к дискам, то от параллелности/последовательности разницы не будет.
Понятно, что не факт, и скорее всего, что не будет, но надо попробовать )
В 11.2 PQ_CONCURRENT_UNION не канает похоже.
Найти бы пример или суть, как распараллелить через pipeline-функции (если это возможно, не используя scheduler и job-ы).

Добрый Э - Эхэто до первого фетча или возврат полного набора итоговых данных?
Полный набор.

Egoроптимизатор любит искать в таких unionах одинаковые условия в where и выность их наружу из union.
Запросы с условиями, но по плану вроде ничего не выносит.
pihelРаспараллельте физически любым из способов
Спасибо, видел, но во-первых, не понял механизм, во-вторых, предположим, делаю несколько pipeline.
Не пойму как потом собрать их результат в кучу и вообще как получить результат.

EgoрЗависит от того, что потом нужно делать с результатом. Можно, например, сложить в промежуточную таблицу.
Придется юзать постоянную таблицу с генерацией уникальных id запросов и т.д., что вряд ли будет сильно эффективнее,
а во временные складывать в других потоках смысла нет, не увидишь потом, так ведь?
И самое главное - dml-ить нельзя - т.к. обращение к функции, где этот запрос идет как


-2-Можно сделать пипелин, который запускает несколько процессов и ожидает от них данные через pipe или aq. Плюс, контролирует завершение всех процессов через тот же механизм.
Не знаю прокатит ли, посмотрю пайп, хотя запускать-то все равно через джобы...
Видимо, пока без вариантов.