How GaiaDB 4.0 Supercharges Complex Queries with Parallel Execution

Enterprises typically face two data‑processing scenarios: OLTP for transactional workloads and OLAP for analytical reporting. To serve both, they adopt either an OLTP + OLAP combination with ETL sync or a distributed HTAP database that hides data‑sync complexity.

GaiaDB 4.0 adds native parallel query capability, allowing a single MySQL‑compatible cluster to handle both transactional (TP) and analytical (AP) queries without code changes. By partitioning data and executing scan, gather, and other operators across multiple CPU cores, query latency drops from dozens of seconds to a few seconds.

The implementation parallelizes operators such as scan and gather . Data is split into partitions, dispatched to worker threads, and intermediate results are aggregated by a leader thread. This design introduces a stream operator for inter‑thread data exchange, ensuring correctness while maximizing CPU utilization.

Supported Parallel Operators

Parallel Filter (WHERE/HAVING)

Parallel Scan (Projection)

Parallel Join (HashJoin, NestLoopJoin, SemiJoin)

Parallel Aggregation (SUM, AVG, COUNT, BIT_AND, BIT_OR, BIT_XOR)

Parallel Sort (ORDER BY)

Parallel Group‑by

Other parallel operators (LIMIT/OFFSET, UNION, etc.)

Performance tests on TPC‑H show GaiaDB achieving up to 14× speedup for single‑table complex queries and an average of more than 8× improvement compared with single‑threaded MySQL on a 32‑core, 128 GB RAM platform.

To enable parallel execution, set the following global parameters:

SET force_parallel_execute=ON

SET parallel_default_dop=4

// default parallelism degree SET parallel_cost_threshold=1000 // cost threshold to trigger parallelism

Alternatively, use the hint syntax on a specific SQL statement, e.g. SELECT /*+ PQ(8) */ … FROM … to run with eight parallel threads.

GaiaDB also introduces column‑store indexes to further accelerate query performance by storing selected columns in a compressed, columnar format.