When Adaptive Server is configured for parallel query processing, the query optimizer evaluates each query to determine whether it is eligible for parallel execution. If it is eligible, and if the optimizer determines that a parallel query plan can deliver results faster than a serial plan, the query is divided into plan fragments that are processed simultaneously. The results are combined and delivered to the client in a shorter period of time than it takes to process the query serially as a single fragment. Parallel query processing can improve the performance of:
select statements that scan large numbers of pages but return relatively few rows, such as table scans or clustered index scans with grouped or ungrouped aggregates.
Table scans or clustered index scans that scan a large number of pages, but have where clauses that return only a small percentage of rows.
select statements that include union, order by, or distinct, since these query operations can make use of parallel sorting or parallel hashing.
select statements where a reformatting strategy is chosen by the optimizer, since these can populate worktables in parallel and can make use of parallel sorting.
join queries.
Commands that return large, unsorted result sets are unlikely to benefit from parallel processing due to network constraints. In most cases, results can be returned from the database faster than they can be merged and returned to the client over the network.
Parallel DMLs like insert, delete, and update are not supported and so do not benefit from parallelism.
