A query is more likely to use parallelism if the query processes a lot more rows than are returned. In this case, the number of rows processed includes the size of all rows scanned plus the size of all intermediate results. It does not include rows that are never scanned because an index is used to skip most of the table. An ideal case is a single-row GROUP BY over a large table, which scans many rows and returns only one. Multi-group queries are also candidates if the size of the groups is large. Any predicate or join condition that drops a lot of rows is also a good candidate for parallel processing.

Following is a list of circumstances in which a query can not take advantage of parallelism, either at optimization or execution time:

See also

• Parallelism during query execution
• Threading in SQL Anywhere
• max_query_tasks option [database]
• priority option [database]
• max_query_tasks, priority, NumLogicalProcessorsUsed, and ActiveReq properties: Server-level properties
• CREATE DATABASE statement
• ALTER TABLE statement