Fanout with MariaDB Xpand

Overview

MariaDB Xpand is able to use multiple CPUs for query processing and operations like ALTER TABLE. This process is called Fanout.

When Xpand executes a query, it is split into fragments for execution. These fragments are then passed to the various CPUs for execution. Depending on the query type and complexity, each fragment can have multiple stages of execution.

Fanout is the process by which fragments of a query are run simultaneously on multiple CPUs per node. This allows for expanded parallelism and much shorter execution times for ALTER TABLE and large OLAP queries. For additional information about query execution and fragmentation, see "Parallel Query Evaluation for MariaDB Xpand".

Note

Fanout is not available for temporary tables. Temporary tables contain only one slice and reside on only one node.

Variables that Control Fanout

Fanout is controlled and configured by the following variables. Default values are appropriate for most workloads.

Fanout Variables

Name

Description

Default Value

Session Variable

query_fanout

Enables query fanout. This takes precedence over all other fanout variables.

True

Yes

query_fanout_insert_select

If enabled, INSERT INTO ... SELECT FROM ... queries will use Fanout. This takes precedence over query_fanout_all_writes.

True

Yes

query_fanout_all_writes

Enable fanout for INSERT, UPDATE, and DELETE queries. Order of writes is not guaranteed.

False

Yes

query_fanout_min_rows

Sets the minimum number of rows for fanout, which is determined by the estimate in the query plan. If a query plan estimates that fewer rows will be read than the minimum, then fanout will not occur for the query.

5000

Yes

Disable Fanout

This will completely disable Fanout and each query will use only one CPU. This will affect performance and this setting should only be changed if advised by MariaDB Support.

sql> SET query_fanout = FALSE;

Table Slicing Guidelines for Optimal Fanout

To provide full parallelism with Fanout, ensure that the representations queried have enough slices. Large tables that are expected to benefit from Fanout should be sliced to the total number of CPU cores licensed for the cluster. Under-slicing reduces parallelism. For example, if three slices of a representation are present on a node, then Fanout is limited to running a maximum of three query fragments on three CPUs of that node.

Caveats

  • Fanout is not available for temporary tables. Temporary tables contain only one slice and reside on only one node.