Run a parallel query / set the degree of parallelism

Oracle

-- At query level with a hint:
SELECT /*+ PARALLEL(t, 4) */ * FROM big_table t;
-- Force at session level:
ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4;

The PARALLEL hint applies a parallel scan to the table; degree=DOP. An excessive DOP exhausts server resources, choose it carefully. parallel_degree_policy=AUTO manages it automatically.

PostgreSQL

-- Set the number of parallel workers for the session:
SET max_parallel_workers_per_gather = 4;
-- The planner adds a Gather/Gather Merge node:
EXPLAIN (ANALYZE) SELECT count(*) FROM big_table;

If Gather/Parallel Seq Scan appears in the plan, parallelism is in effect. max_parallel_workers and min_parallel_table_scan_size also play a role.

MySQL

-- Limited InnoDB parallelism (certain operations only):
SET GLOBAL innodb_parallel_read_threads = 4;
-- Effective for COUNT(*) and primary key scans.

MySQL does not offer general parallel query execution; innodb_parallel_read_threads only parallelizes clustered index scans (e.g. COUNT(*)). Complex JOINs are single-threaded.

SQL Server

-- MAXDOP hint at query level:
SELECT * FROM dbo.big_table OPTION (MAXDOP 4);
-- Instance level: sp_configure 'max degree of parallelism', 4;

MAXDOP limits the number of parallel threads; MAXDOP 1 disables parallelism. Once the 'cost threshold for parallelism' is exceeded, the plan goes parallel.

MongoDB

// Allow disk use for a large aggregation:
db.sale.aggregate([ { $group: { _id: "$city", t: { $sum: "$amount" } } } ], { allowDiskUse: true })
// A sharded cluster processes each shard in parallel.

In a sharded cluster the query runs on each shard in parallel; on a single node aggregation stages are mostly sequential. allowDiskUse enables operations that exceed the memory limit.

Redis

# Not applicable: there is no concept of query parallelism.

Command execution is single-threaded; scale with Cluster (sharding) or use io-threads for network I/O parallelism.

Elasticsearch

# Shard count = unit of parallelism; a query runs in parallel across shards.
# Parallelism by slicing within a single shard (with scroll/PIT):
GET <index>/_search
{ "slice": { "id": 0, "max": 4 }, "query": { "match_all": {} } }

A search runs concurrently on all relevant shards; the number of primary shards sets the baseline level of parallelism. slices split large scroll/reindex operations.