Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #1297 from bsingr/patch-3 

Correct some typos in documentation about indexes.
This commit is contained in:
Thomas Schmidts 2015-04-07 15:48:20 +02:00
parent b707f690b2 b33c4c6a59
commit 799a3bf9a2
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/Books/Users/IndexHandling/WhichIndex.mdpp
View File

@ -24,10 +24,10 @@ different usage scenarios:
attribute(s) are equality comparisons. It will be the most efficient index
type if the index is declared unique.
Insertions into a non-unique hash index are also very efficent. Update and
Insertions into a non-unique hash index are also very efficient. Update and
removal performance in a non-unique hash index depend on the key selectivity.
If the selectivity is low and keys repeat a lot, update and removal performance
in a non-unique hash index will degarde.
in a non-unique hash index will degrade.
A non-unique hash index should therefore not be used if duplicate index values
are allowed and it is known that there will be many duplicate values in the index
@ -60,14 +60,14 @@ different usage scenarios:
Geo indexes will only be invoked via special functions.
- fulltext index: a fulltext index can be used to index all words contained in
- full-text index: a full-text index can be used to index all words contained in
a specific attribute of all documents in a collection. Only words with a
(specifiable) minimum length are indexed. Word tokenization is done using
the word boundary analysis provided by libicu, which is taking into account
the selected language provided at server start.
The index supports complete match queries (full words) and prefix queries.
Fulltexts indexes will only be invoked via special functions.
Full-text indexes will only be invoked via special functions.
- cap constraint: the cap constraint provided by ArangoDB indexes documents
not to speed up search queries, but to limit (cap) the number or size of
@ -120,7 +120,7 @@ the lookup value cannot be `null`, a sparse index may be used. When uncertain, t
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
will not know beforehand whether the comparison values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)