Parallel Query Execution

Goal

Add parallel query execution to MariaDB Server so that long-running analytical statements can scale across multiple cores by splitting work across worker threads, with linear-ish speedup proportional to thread count (~70% of the theoretical maximum, per Monty's estimate in MDEV-6096).
In scope: pure {{SELECT}}s on InnoDB tables with one or more tables, including group-by, where the optimizer estimates the serial cost above a threshold and where executing in parallel does not increase user-perceived latency.
Out of scope (for the first ship): write paths, parallel DML, plans involving variable assignment (@a := value), engines that cannot share a read snapshot, queries cheaper than parallel_query_min_cost.

Why an Epic instead of using MDEV-6096

MDEV-6096 has been the de-facto thinking-space for parallel query since 2014. Its title is "Research - Ideas about…" and its description is a design memo, not a feature brief. Treating it as the umbrella confuses "research phase" with "feature shipment". This Epic now owns the feature; MDEV-6096 stays as the research artifact and is one of the Epic's children.

Workstreams

The current implementation is split between two devs. Stories under this Epic group as follows:
Storage-engine plumbing — Oleg Smirnov

MDEV-39489 — study how to use the same read snapshot across workers
MDEV-39491 — split the table/index into chunks to read (storage-engine "position at N%")
MDEV-39652 — query plan shape: parallel table scan + group

Worker-thread plumbing & result shipping — Rex Johnston

MDEV-39492 — how to create worker threads (thread pool? INSERT-DELAYED pattern?)
MDEV-39495 — use temporary work tables to ship results from worker → primary
MDEV-39638 — open per-worker handler/TABLE objects

Pre-existing related stories (older OPEN siblings)

MDEV-5004 — parallel read transactions on the same snapshot (precondition for snapshot work above)
MDEV-18705 — parallel index range scan
MDEV-27717 — parallel execution on partitions where multiple partitions are needed

Research artifact

MDEV-6096 — original 2014 research/ideas ticket

Related but not children

MDEV-26157 — Prototype OpenMP in addressing parallel queries (already an Epic of its own, hence not a child here). Treat as a sibling exploration; revisit if OpenMP becomes a viable substrate.
TODO-5462 — review queue for the older replay MDEVs (separate Epic MDEV-39836); listed here only because some of the same engineers are involved.

Status snapshot (as of creation)

Total logged effort across children to date:

• roughly 40+ engineer-days, mostly on the two STALLED studies (MDEV-39492 ~16d, MDEV-39491 ~13d).

Success criteria

• An analytical query crossing parallel_query_min_cost on InnoDB runs across N worker threads with a measurable speedup vs. serial, at ≥70% of the theoretical N× ceiling on the reference benchmark.
• The feature is gated by server variables (parallel_max_running_threads, parallel_worker_threads, parallel_query_min_cost) — off by default for the first release.
• Worker threads are visible in INFORMATION_SCHEMA.PROCESSLIST and performance_schema.threads.
  KILL of either the primary or any worker terminates the whole parallel query cleanly.
• All existing MTR tests pass with the feature enabled (no regressions to serial plans).
• Documentation page covering tuning variables, when the optimizer chooses a parallel plan, and known limitations.

Non-goals for this Epic

• Cross-engine parallelism (MyISAM/RocksDB) — out of scope; would need separate snapshot-sharing work per engine.
• Spider-like cross-node parallelism — covered separately by Spider/MaxScale work.
• Parallel DML or parallel index build — separate Epics if pursued.

Target release

Fix Version: 13.1. To be re-evaluated mid-Q3/2026 once the two STALLED studies are unblocked.

Tracking

This Epic is the single ticket to follow for "is parallel query done?". When all children are CLOSED, the feature ships. New parallel-query bugs and stories should be labeled parallel-query-2026 and linked here as Epic children.