New Indexes chapter (neo4j#770)

modules/ROOT/content-nav.adoc

@@ -76,9 +76,15 @@
 ** xref:functions/database.adoc[]
 ** xref:functions/user-defined.adoc[]
 
-* xref:indexes-for-search-performance.adoc[]
-* xref:indexes-for-full-text-search.adoc[]
-* xref:indexes-for-vector-search.adoc[]
+* xref:indexes/index.adoc[]
+** xref:indexes/search-performance-indexes/overview.adoc[]
+*** xref:indexes/search-performance-indexes/managing-indexes.adoc[]
+*** xref:indexes/search-performance-indexes/using-indexes.adoc[]
+*** xref:indexes/search-performance-indexes/index-hints.adoc[]
+** xref:indexes/semantic-indexes/overview.adoc[]
+*** xref:indexes/semantic-indexes/full-text-indexes.adoc[]
+*** xref:indexes/semantic-indexes/vector-indexes.adoc[]
+** xref:indexes/syntax.adoc[]
 
 * xref:constraints/index.adoc[]
 ** xref:constraints/syntax.adoc[]
@@ -91,10 +97,8 @@
 ** xref:planning-and-tuning/runtimes/index.adoc[]
 *** xref:planning-and-tuning/runtimes/concepts.adoc[Concepts]
 *** xref:planning-and-tuning/runtimes/reference.adoc[]
-** xref:planning-and-tuning/query-tuning/index.adoc[]
-*** xref:planning-and-tuning/query-tuning/indexes.adoc[]
-*** xref:planning-and-tuning/query-tuning/using.adoc[]
-*** xref:planning-and-tuning/query-tuning/query-options.adoc[]
+** xref:planning-and-tuning/query-tuning.adoc[]
+
 
 * xref:query-caches/index.adoc[]
 ** xref:query-caches/unified-query-caches.adoc[]

modules/ROOT/pages/appendix/tutorials/advanced-query-tuning.adoc

@@ -5,7 +5,7 @@
 This page describes advanced query optimizations based on native index capabilities.
 
 One of the most important and useful ways of optimizing Cypher queries involves creating appropriate indexes.
-This is described in more detail in xref::indexes-for-search-performance.adoc[], and demonstrated in xref::appendix/tutorials/basic-query-tuning.adoc[].
+This is described in more detail in xref:indexes/search-performance-indexes/managing-indexes.adoc[], and demonstrated in xref::appendix/tutorials/basic-query-tuning.adoc[].
 In summary, an index will be based on the combination of a `Label` and a `property`.
 Any Cypher query that searches for nodes with a specific label and some predicate on the property (equality, range or existence) will be planned to use
 the index if the cost planner deems that to be the most efficient solution.

modules/ROOT/pages/appendix/tutorials/basic-query-tuning.adoc

@@ -764,5 +764,5 @@ Total database accesses: 5, total allocated memory: 184
 1 row
 ----
 
-Our execution plan is down to a single row and uses the xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-index-seek[Node Index Seek] operator which does an index seek (see xref::indexes-for-search-performance.adoc[]) to find the appropriate node.
+Our execution plan is down to a single row and uses the xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-index-seek[Node Index Seek] operator which does an index seek (see xref::indexes/search-performance-indexes/managing-indexes.adoc[]) to find the appropriate node.
 

modules/ROOT/pages/clauses/index.adoc

@@ -234,22 +234,22 @@ m| xref:clauses/transaction-clauses.adoc#query-terminate-transactions[TERMINATE
 == Reading hints
 
 These comprise clauses used to specify planner hints when tuning a query.
-More details regarding the usage of these -- and query tuning in general -- can be found in xref::planning-and-tuning/query-tuning/using.adoc[Planner hints and the USING keyword].
+More details regarding the usage of these -- and query tuning in general -- can be found in xref::indexes/search-performance-indexes/index-hints.adoc[Planner hints and the USING keyword].
 
 [options="header"]
 |===
 | Hint | Description
 
-m| xref::planning-and-tuning/query-tuning/using.adoc#query-using-index-hint[USING INDEX]
+m| xref::indexes/search-performance-indexes/index-hints.adoc#query-using-index-hint[USING INDEX]
 | Index hints are used to specify which index, if any, the planner should use as a starting point.
 
-m| xref::planning-and-tuning/query-tuning/using.adoc#query-using-index-hint[USING INDEX SEEK]
+m| xref::indexes/search-performance-indexes/index-hints.adoc#query-using-index-hint[USING INDEX SEEK]
 | Index seek hint instructs the planner to use an index seek for this clause.
 
-m| xref::planning-and-tuning/query-tuning/using.adoc#query-using-scan-hint[USING SCAN]
+m| xref::indexes/search-performance-indexes/index-hints.adoc#query-using-scan-hint[USING SCAN]
 | Scan hints are used to force the planner to do a label scan (followed by a filtering operation) instead of using an index.
 
-m| xref::planning-and-tuning/query-tuning/using.adoc#query-using-join-hint[USING JOIN]
+m| xref::indexes/search-performance-indexes/index-hints.adoc#query-using-join-hint[USING JOIN]
 | Join hints are used to enforce a join operation at specified points.
 
 |===
@@ -263,7 +263,7 @@ These comprise clauses to create, show, and drop indexes and constraints.
 |===
 | Clause | Description
 
-m| xref::indexes-for-search-performance.adoc#indexes-syntax[CREATE \| SHOW  \| DROP INDEX]
+m| xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-syntax[CREATE \| SHOW  \| DROP INDEX]
 | Create, show or drop an index.
 
 m| xref::constraints/syntax.adoc[CREATE \| SHOW \| DROP CONSTRAINT]

modules/ROOT/pages/clauses/match.adoc

@@ -24,7 +24,7 @@ Cypher is declarative, and so usually the query itself does not specify the algo
 Neo4j will automatically work out the best approach to finding start nodes and matching patterns.
 Predicates in `WHERE` parts can be evaluated before pattern matching, during pattern matching, or after finding matches.
 However, there are cases where you can influence the decisions taken by the query compiler.
-Read more about indexes in xref::indexes-for-search-performance.adoc[], and more about specifying hints to force Neo4j to solve a query in a specific way in xref::planning-and-tuning/query-tuning/using.adoc[Planner hints and the USING keyword].
+Read more about indexes in xref:indexes/search-performance-indexes/managing-indexes.adoc[], and more about specifying hints to force Neo4j to solve a query in a specific way in xref::indexes/search-performance-indexes/index-hints.adoc[Planner hints and the USING keyword].
 
 
 [[match-example-graph]]

modules/ROOT/pages/clauses/merge.adoc

@@ -15,7 +15,7 @@ If there isn't a node with the specific `name` property, a new node will be crea
 [NOTE]
 ====
 For performance reasons, creating a schema index on the label or property is highly recommended when using `MERGE`.
-See xref::indexes-for-search-performance.adoc[] for more information.
+See xref:indexes/search-performance-indexes/managing-indexes.adoc[] for more information.
 ====
 
 When using `MERGE` on full patterns, the behavior is that either the whole pattern matches, or the whole pattern is created.

modules/ROOT/pages/clauses/transaction-clauses.adoc

@@ -82,7 +82,7 @@ m| MAP
 m| planner
 a|
 The name of the Cypher planner used to plan the query currently executing in this transaction, or an empty string if no query is currently executing.
-For details, see xref::planning-and-tuning/query-tuning/index.adoc#cypher-planner[Cypher planner].
+For details, see xref::planning-and-tuning/query-tuning.adoc#cypher-planner[Cypher planner].
 m| STRING
 
 m| runtime

modules/ROOT/pages/clauses/where.adoc

@@ -16,7 +16,7 @@ In the case of `WITH`, however, `WHERE` simply filters the results.
 In the case of multiple `MATCH` / `OPTIONAL MATCH` clauses, the predicate in `WHERE` is always a part of the patterns in the directly preceding `MATCH` / `OPTIONAL MATCH`.
 Both results and performance may be impacted if `WHERE` is put inside the wrong `MATCH` clause.
 
-xref::indexes-for-search-performance.adoc[Indexes] may be used to optimize queries using `WHERE` in a variety of cases.
+xref:indexes/search-performance-indexes/managing-indexes.adoc[Indexes] may be used to optimize queries using `WHERE` in a variety of cases.
 
 [[where-example-graph]]
 == Example graph

modules/ROOT/pages/constraints/examples.adoc

@@ -325,7 +325,7 @@ CREATE CONSTRAINT book_title FOR (book:Book) REQUIRE book.title IS UNIQUE
 ----
 
 In this case, the constraint cannot be created because it is in conflict with the existing graph.
-Either use xref::indexes-for-search-performance.adoc[] instead, or remove/correct the offending nodes and then re-apply the constraint.
+Either use xref:indexes/search-performance-indexes/managing-indexes.adoc[] instead, or remove/correct the offending nodes and then re-apply the constraint.
 
 .Error message
 [source, error]
@@ -672,7 +672,7 @@ CREATE CONSTRAINT series_title FOR ()-[sequel:SEQUEL_OF]-() REQUIRE (sequel.seri
 ----
 
 In this case, the constraint cannot be created because it is in conflict with the existing graph.
-Either use xref::indexes-for-search-performance.adoc[] instead, or remove/correct the offending relationships and then re-apply the constraint.
+Either use xref:indexes/search-performance-indexes/managing-indexes.adoc[] instead, or remove/correct the offending relationships and then re-apply the constraint.
 
 .Error message
 [source, error]
@@ -2368,7 +2368,7 @@ CREATE CONSTRAINT actor_born FOR (actor:Actor) REQUIRE (actor.born) IS NODE KEY
 ----
 
 In this case, the node key constraint cannot be created because it is in conflict with the existing graph.
-Either use xref::indexes-for-search-performance.adoc[] instead, or remove/correct the offending nodes and then re-apply the constraint.
+Either use xref:indexes/search-performance-indexes/managing-indexes.adoc[] instead, or remove/correct the offending nodes and then re-apply the constraint.
 
 .Error message
 [source, error]
@@ -2729,7 +2729,7 @@ CREATE CONSTRAINT knows_level FOR ()-[knows:KNOWS]-() REQUIRE (knows.level) IS R
 ----
 
 In this case, the relationship key constraint cannot be created because it is in conflict with the existing graph.
-Either use xref::indexes-for-search-performance.adoc[] instead, or remove or correct the offending relationships and then re-apply the constraint.
+Either use xref:indexes/search-performance-indexes/managing-indexes.adoc[] instead, or remove or correct the offending relationships and then re-apply the constraint.
 
 .Error message
 [source, error]

modules/ROOT/pages/constraints/index.adoc

@@ -121,6 +121,6 @@ Creating a constraint has the following implications on indexes:
 * Adding a node key, relationship key, or property uniqueness constraint on a single property also adds an index on that property, and therefore, an index of the same index type, label/relationship type, and property combination cannot be added separately.
 * Adding a node key, relationship key, or property uniqueness constraint for a set of properties also adds an index on those properties, and therefore, an index of the same index type, label/relationship type, and properties combination cannot be added separately.
 * Cypher will use these indexes for lookups just like other indexes.
-  Refer to xref::indexes-for-search-performance.adoc[] for more details on indexes.
+  Refer to xref:indexes/search-performance-indexes/managing-indexes.adoc[] for more details on indexes.
 * If a node key, relationship key, or property uniqueness constraint is dropped and the backing index is still required, the index need to be created explicitly.