DDL Forwarding for Reference Tables

Data Definition Language (DDL) commands for reference tables can be run from the master aggregator or a child aggregator node. DDL commands run on a child aggregator are forwarded to the master aggregator and propagated from there. (See Cluster Management Commands for more information.)

The enable_query_forwarding engine variable controls the DDL query forwarding for all database tables including reference tables.

DML Forwarding for Reference Tables

Data Manipulation Language (DML) commands for reference tables can be run from the master aggregator or a child aggregator node, however, with some exceptions. The following DML commands must be run directly on the master aggregator; they will fail with an error when run on a child aggregator.

• The LOAD DATA command

• Query profiling commands such as PROFILE and SHOW PROFILE if the sync_permissionsengine variable is set to ON.

• DML statements used in stored procedures

• DML queries that reference temporary tables

• DML queries in multi-statement transactions that are enclosed within BEGIN and COMMIT transaction statements.

DDL commands run on a child aggregator are forwarded to the master aggregator and propagated from there. (See Cluster Management Commands for more information.)

The enable_dml_query_forwarding engine variable controls the DML query forwarding for reference tables.

Global Temporary Tables

Another type of temporary table is the global temporary table. Like temporary tables, they are not persisted.

Unlike temporary tables, global temporary tables are shared across sessions, i.e. they exist beyond the duration of a session. They are never automatically dropped and must always be dropped manually. They can also be queried by other users since they are not session dependent.

Global temporary tables can be used as a temporary space for processing data that can be accessed from multiple connections, for example, performing ETL (Extract, Transform, and Load) operations on modern dynamic databases.

If failover occurs, global temporary tables lose data and enter an errored state; they need to be dropped and recreated. However, dropping a global or non-global temporary table does not drop its plancache from the disk and retains the cache if the table is recreated with the same schema.

DDL such as CREATE ROWSTORE GLOBAL TEMPORARY TABLE and DML for global temporary tables can be run on a master, or a child aggregator node.

Note: Both global temporary tables and non-global temporary tables cannot be altered.

Skiplist Indexes

The default index type in SingleStore is a skiplist. Skiplists in SingleStore are meant to replace the B-Tree indexes used by most other databases, including MySQL. Skiplists are optimized to run in memory as they can be implemented lock free and offer extremely fast insert performance. Like B-Trees, they offer an expected O(log(n)) lookup performance and can be traversed in sorted order.

Unlike B-Trees in MySQL, skiplists in SingleStore are uni-directional (singly linked). Each column in a compound skiplist index can be specified as ascending (ASC) or descending (DESC). The default is ASC. Which one you pick will not impact lookup performance, but it does impact scan performance depending on the direction the index is scanned. Scanning a skiplist in reverse order is approximately twice as costly as scanning in forward order. So, if you have an ASC index and you run a query that would traverse the index in descending order (ORDER BY DESC for example), then the query will require a more expensive iteration than if the index were DESC.

SingleStore supports skiplists only on rowstore tables. For more information on what a skiplist is and why it is used in SingleStore see: The Story Behind SingleStore’s Skiplist Indexes

Columnstore Indexes

Columnstore indexes leverage columnstore technology to efficiently store and retrieve large numbers of values from disk (using flash or SSD is recommended). Because columnstore indexes are backed by disk and don’t have the requirement that all data must fit in memory, they are typically very useful for analytical workloads. SingleStore currently supports sort key indexes which, when added to a table, will make the entire table structure backed by the columnstore. Currently columnstore indexes cannot be combined with in-memory row store indexes on the same table. For more information about using columnstore indexes in SingleStore, see How the Columnstore Works.

Hash Indexes

Due to the restrictive case detailed above, HASH indexes should only be used when there is a demonstrated need and measurable benefit on your particular dataset and workload. In these specific cases, HASH indexes provide fast exact-match access to unique values. This is because the hash index is stored in a sparse array of buckets indexed by a hash function on the relevant columns eg: hash(column_a, column_b). Queries can quickly find exact match data by examining only the bucket identified by the hash function. However they cannot easily scan over a subset of the index. For multi-column indexes, query filters must match all of the index columns to be able to take advantage of the index. SingleStore supports HASH indexes on both columnstore and rowstore tables. For more information, see USING HASH behavior and Highly Selective Joins.

Consider an example table:

CREATE TABLE t(a int, b int, INDEX(a, b) USING HASH);

Suppose we are running queries like:

SELECT * FROM t WHERE a < 3;

EXPLAIN shows us that since we are performing a range scan and not filtering on all the columns in our hash index, a full Table Scan is performed.

EXPLAIN SELECT * FROM t WHERE a < 3;

+------------------------------------------------+
| EXPLAIN                                        |
+------------------------------------------------+
| Gather partitions:all                          |
| Project [t.a, t.b]                             |
| Filter [t.a < 3]                               |
| TableScan db.t                                 |
+------------------------------------------------+

The hash index is only utilized if the query uses only equality predicates, and filters on all columns in the hash index.

EXPLAIN SELECT * FROM t WHERE a=3 AND b=7;

+--------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                  |
+--------------------------------------------------------------------------------------------------------------------------+
| Gather partitions:all                                                                                                    |
| Project [t.a, t.b]                                                                                                       |
| IndexRangeScan db.t, KEY a (a, b) USING HASH storage:lf_hashtable scan:[a = 3 AND b = 7]                                 |
+--------------------------------------------------------------------------------------------------------------------------+

Runtime Plan Choosing

SingleStore can dynamically select which index to use for a query at runtime. Instead of collecting statistics and building histograms, SingleStore can compute these statistics for a given query on-demand by inspecting its indexes. If a query can match more than one index, SingleStore compiles an execution plan for each choice, along with the necessary expression logic to cheaply analyze and evaluate which plan to choose at runtime. This process eliminates the need to manually recompute statistics on indexes.

Index Hints

SingleStore supports the following index hint syntax:

tbl_name [index_hint]

index_hint:
    USE {INDEX | KEY} (index_list)
  | IGNORE {INDEX | KEY} (index_list)
  | FORCE {INDEX | KEY} (index_list)

index_list:
    index_name [, index_name] ...

For example:

SELECT * FROM t1 USE INDEX(idx_name);

--OR

SELECT * FROM t1 FORCE INDEX(idx_name);

• USE and FORCE hints force the use of one of the specified indexes to run the query. In SingleStore, there is no difference between a USE and FORCE hint.

• IGNORE hints disallow the specified indexes from being used to run the query.

The EXPLAIN <query> statement can be used to show which indexes the query considers and which one it will actually use.

Index Commands

• CREATE INDEX

• DROP INDEX

• SHOW INDEX, SHOW INDEXES, SHOW KEYS

• SHOW INDEXES

• SHOW KEYS

• EXPLAIN

Related Commands

An index may also be specified when creating or altering tables.

• CREATE TABLE

• ALTER TABLE

Related Topics

• Training: SingleStore Indexes