Flexible Parallelism

SingleStore supports Flexible Parallelism, which allows multiple cores on the same node to access the same database partition. To use Flexible Parallelism, it must be enabled prior to database creation.

With Flexible Parallelism, as database partitions are created, they are divided into sub-partitions. As a query runs on a leaf node, multiple cores working on behalf of the query can process different sub-partitions of a partition in parallel.

As an example, if you are currently at one partition per core with Flexible Parallelism, doubling the size of your workspace and then rebalancing will result in two cores for each partition. As a result, a simple query that scans and aggregates all the data in a single partition will now execute more quickly than it did before.

Typically, analytic or hybrid transactional/analytic workloads will gain some benefits from Flexible Parallelism, especially over time as you add more hardware and rebalance workspaces. Strictly OLTP workloads will tend to not benefit from enabling Flexible Parallelism.

As you add cores to your SingleStore system, you can reach a point where you have more cores than database partitions on each leaf node. Without Flexible Parallelism, there is a limit of one core accessing each database partition; therefore, the maximum ratio of cores to partitions is 1:1. This can lead to a kind of bottleneck as you can have idle cores on a node where you have queries accessing a single partition.

Note

When Flexible Parallelism is enabled, all new databases created will use Flexible Parallelism. Existing databases use the maximum of one thread per partition. You cannot enable or disable Flexible Parallelism on existing databases.

Flexible Parallelism is enabled by default for new workspaces in SingleStore Helios with the following settings:

  • One physical partition per leaf core at database creation time

  • 16 sub-partitions per physical partition

  • One thread per leaf core per query

If you’re an existing customer who began using SingleStore Helios before May 2022, and wish to have Flexible Parallelism enabled for new databases, contact Support.

Note

SingleStore recommends lowering parallelism by setting query_parallelism_per_leaf_core = .01 for high-throughput search workloads. This setting will limit parallelism to one thread per query per leaf node.

The default setting query_parallelism_per_leaf_core = 1 indicates a parallelism of one thread per core for each query. With this setting all cores would be used for a query.

Sub-segment Elimination

Sub-segment elimination improves performance by eliminating data at the sub-segment level during query processing and thus extends the performance improvements provided by segment elimination.

Segments consist of blocks of 4096 rows each. With sub-segment elimination, statistics are collected for blocks and are used during query processing to eliminate blocks. Sub-segment elimination is restricted to sort key columns.

A segment with the default size (columnstore_segment_rows = 1,024,000) would have 1,024,000 / 4,096 = 250 sub-segments. Queries with highly selective predicates using flexible parallelism are expected to see performance improvements due to sub-segment elimination.

Consider a table and a query as follows:

CREATE TABLE sales(id INT, dt DATETIME, itemnum INT, qty FLOAT, price numeric(18,4), SORT KEY(dt));
SELECT itemnum, SUM(qty*price)
FROM sales
WHERE dt BETWEEN "2024-09-20 17:00:00" AND "2024-09-20 17:01:00"
GROUP BY all;

This query has a very narrow time range (a highly selective predicate) on the dt column, and the dt column is the sort key. Sub-segment elimination will be applied to this query and is expected to improve the performance of this query.

Last modified: November 5, 2024

Was this article helpful?