Привет всем!
SY уже указал раздел документации, где Оракл гарантирует сохранение порядка UNION ALL "как записано на экране".
В
https://docs.oracle.com/database/121/VLDBG/GUID-1F4C90F9-3EF5-423A-B55B-2593FB3F1433.htm сказано:
авторHowever, unlike the sequential processing of one branch after another, the concurrent processing does not guarantee an ordered return of the results of the individual branches.
Мое прочтение, что фраза "
в отличие от последовательного исполнения, параллельное исполнение
не гарантирует упорядоченный результат", гарантирует упорядоченный результат для не-параллельного исполнения, и несет вес документации производителя.
Вот один из менее трудоемких способов задать порядок возврата строчек "как в тексте", без ручной перенумерации при передвижении строк вверх/вниз, который пришел на ум:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- монотонно растущий счетчик для поддержки натурально упорядоченных UNION ALL запросов
create sequence sq
minvalue 1
maxvalue 999999999999999999999999999
start with 1
increment by 1;
.........
select /*+ PQ_CONCURRENT_UNION(@"SET$1") */ val from (
select sq.nextval, 'П' val from dual union all
select sq.nextval, 'р' from dual union all
select sq.nextval, 'и' from dual union all
select sq.nextval, 'м' from dual union all
select sq.nextval, 'е' from dual union all
select sq.nextval, 'р' from dual
order by 1)
Пример упрощен для читабельности, в реальности многие из строк - кандидаты для параллельного исполнения.
Этот код отвечает моим требованиям: разрешить параллельное исполнение, сохранить порядок результата как в коде, не требовать ручной (и подверженной ошибкам) перенумерации при изменении порядок строчек в коде.
К сожалению, он полагается на то, что Оракл начнет исполнение в порядке написания, а таких гарантий у Оракла я не нашел.
По вопросам уважаемых участников:
Меня больше интересует принципиальные вопросы:
1. Если порядок важен, то почему не указан order by?
2. Какой смысл хотеть параллельного выполнения, если хочется, чтобы сначала вернулись строки в порядке указания частей union all? Ведь это означает лишнюю работу, если фетч прекратится досрочно и зря простаивающие слейвы пока фетчатся предыдущие части.
1. Order by - предпочтительный метод, я считаю. Полагаться на задокументируемые аспекты поведения - плохая практика.
К сожалению, не предусмотрен удобный ключ сортировки соответствующий номеру строки, как в PL/SQL.
Добавление числа вызывает неудобства ручной перенумерации, описанные в первом сообщении.
2. Смысл в том, чтобы время исполнения всего запроса не слишком превышало время исполнения самого долгого из подзапросов.
Например, подзапросы ходят в интернет, у которого при обрыве связи тайм аут может достигать десятки секунд. UNION ALL из сотни непараллельных запросов может подвиснуть на час, а параллельных - завершится в пределах минуты.
