Important
The SingleStore 9.1 release candidate (RC) is available now. It will be promoted to general availability (GA) soon and at that time it will be renamed to SingleStore 10.
In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10, while SingleStore 9.0 is recommended for production workloads.
Distributed DML Query Execution
On this page
In this topic we will look at common DML query patterns and how they are executed through the distributed system.
You can use the EXPLAIN command to examine a query’s aggregator-level and leaf-level query plans.
Let’s assume the following schema:
CREATE TABLE a (a1 int,a2 int,a3 int,SHARD KEY (a1, a2),KEY (a3));CREATE TABLE b (b1 int,b2 int,b3 int,SHARD KEY (b1, b2));CREATE REFERENCE TABLE r (r1 int,r2 int,PRIMARY KEY (r1),KEY (r2));
Index Matching
Matching on the shard key or the secondary index.
Matching the Shard Key
If you specify an equality on every column in the shard key, then the aggregator node will direct the query to exactly one partition.
These queries are sent to one partition:
SELECT * FROM a WHERE a1 = 4 AND a2 = 10;SELECT a3, count(*) FROM a WHERE a1 = 4 AND a2 = 10 GROUP BY a3;
These queries are sent to all partitions:
SELECT * FROM a WHERE a1 = 4;SELECT * FROM a WHERE a1 = 4 OR a2 = 10;SELECT * FROM a WHERE a1 IN (4, 5) AND a2 IN (10);
Secondary Index Matching
If your query uses a secondary (non-shard) index, then the aggregator node must send the query to every partition in the cluster.
This query matches the secondary index on the column a3:
SELECT * FROM a WHERE a3 = 5;
No Index Matching
Queries that do not match any index perform a full table scan on all partitions.
Last modified: