ну алгоритм параллельности эмпирический, поэтому лчше оптимизатору прозрачно намекнуть на это, чем надеяться на чудо.
так что делайте через union all и то не факт что оно всегда будет параллелиться.

под намекнуть я имел ввиду код с юнионами из вашего первого сообщения.
Но так как аса имеет автоматический механизм формирования планов, то в зависимости от текущей нагрузки сервера не факт что план будет параллельным всегда.
Почитайте здесь: http://dcx.sybase.com/index.html#1201/en/dbusage/parallelism.html

скажу сразу, я не спец по этому вопросу, но будет лучше, если вы запостите на форум полный план. Может у вас в параметрах сервере жестко задано ограничение в один поток на задачу. Надо смотреть.

и еще, что у вас за сервер, что за дисковый массив? может у вас один диск, так что толку от множества процессоров не будет, т.е. все заткнется на дисковых операциях.
и еще, вы читали инфу по ссылкечто я дал? ALTER DATABASE CALIBRATE PARALLEL READ делали?

а вы запостите план тестового запроса, такого как вы приводили с юнионами.

чему у вас равен параметр сервера: max_query_tasks http://dcx.sybase.com/index.html#1201/en/dbadmin/dboptions-s-5481804.html

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

Если же вам надо сделать именно то, что вы сделали, т.е. внутри хранимки запустить два независимых блока кода параллельно, то можно попробовать другой гарантированно работающий финт - запустить обе функции через trigger event. Тогда они сработают параллельно, и надо будет только засинхронизировать момент их окончания и потом слить. Вот эта статья талантливого и офигенного инженера Брека Картера вам будет архиинтересной и в тему: http://sqlanywhere.blogspot.com/2012/12/intra-procedure-parallelism_5.html

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

костя, во здесь: http://dcx.sybase.com/index.html#1201/en/dbusage/queryopt-s-4716396.html
Написано:
Following is a list of circumstances in which a query can not take advantage of parallelism, either at optimization or execution time:

the server computer does not have multiple processors

t he server computer is not licensed to use multiple processors. You can check this by looking at the NumLogicalProcessorsUsed server property. However, note that hyperthreaded processors are not counted for intra-query parallelism so you must divide the value of NumLogicalProcessorsUsed by two if the computer is hyperthreaded.

the max_query_tasks option is set to 1

the priority option is set to background

the statement containing the query is not a SELECT statement

the value of ActiveReq has been greater than, or equal to, the value of NumLogicalProcessorsUsed at any time in the recent past (divide the number of processors by two if the computer is hyperthreaded)

there are not enough available tasks.


а у тебя как-раз один процессор и 8 логических процессоров, так что внутренний параллелизм именно на том серваке не катит. Так что либо пошаманить с лицензией, либо сделать как написано у брека картера в статье.

хотя не, могу ошибаться. так что за процессор стоит на сервере?
И еще, там нет в плане никакой параллельности.
У параллельности другие индикации в плане: http://dcx.sybase.com/index.html#1201/en/dbusage/abbreviations-plan-queryopt.html
попробуй еще по-быстрому поставить максимальный уровень оптимизации в запросе.

а какой план у этого запроса?

ага, таки параллелит. Может тогда уровень оптимизации попробовать втопить до максимума?