By default, solidDB statement execution uses only one thread per statement regardless of the complexity of the statement search plan. If there is CPU capacity available, statement response time can be reduced by enabling statement execution to distribute part of the effort to multiple CPU threads. If parallel execution is enabled at a time of CPU shortage, average response times stay roughly similar to the default behavior. However, there is more variance in response times.

Parallel SQL functionality enables parallel execution for some parts of SQL statement. When an SQL statement needs a long sequential search from the database engine, a new thread can be started to run the low level scan operation in parallel while the SQL interpreter processes the rows.

Parallel SQL execution works only with the ‘Read Committed’ isolation level. However, in EXPLAIN PLAN output, the keyword PARALLEL is printed even if the current isolation level does not allow parallel execution.

Parallel SQL execution can be enabled or disabled by using the configuration parameter SQL.ParallelSQLEnabled, see SQL section.

Parallel SQL execution does not typically distribute the execution to more than two threads. The execution works best in cases where the SQL interpreter does a lot of processing and a lot of scanning of rows from the database engine. Examples of such cases are aggregate calculations from a full table scan or merge joins with full table scans. In those cases, response times can be expected to be 20 to 50 percent less when using parallel SQL execution. Since the execution is not distributed to more than two threads per statement, the CPU usage does not increase to more than twice the amount used when not using parallel SQL execution.