Partitions
Overview
Partitions are applicable to indexes and define the number of pieces the index will be split into. An index with a single partition will be contained in a single file, this creates a great deal of locking contention and would also increase the amount of disk I/O required to update the single monolithic index file. You can use partitioning to alleviate this contention.
For example, when an index is created with a partition count of 1000 the data that is inserted into the owning schema is deterministically divided into these index partitions. When a schema is queried and an index is used, the index manager knows which partitions contain the values requested by the query and will eliminate the other partitions. This theoretically means that the query would need to read 1,000th of the data and experience 1,000th of the read lock contention. The same goes for inserting.
Updates and deletes
Index partitioning affects updates and deletes in a different way, since the partitions cannot be reliably eliminated by query criteria, all partitions will be scanned for the documents.Example
Creates an index in the WordList:Word schema for the Text field using 1,000 partitions.
CREATE INDEX IX_Text
(
Text
) ON WordList:Word WITH (PARTITIONS = 1000)
Rebuilds an index in the WordList:Word schema setting its partitions to 1,000.
REBUILD INDEX IX_Text ON WordList:Word WITH (PARTITIONS = 1000)
See also
- Rebuild Index
Related
- Create Index - Creates an index to speed up read operations.
- PageSize - Defines the size of a schema page.
- Rebuild Index - Rebuilds an index with a different set of parameters.
- Keywords - A breakdown of all high-level statements available via the query handler.
- Syntax - Basic KBSQL syntax and some examples.