Type constraint index tuning (#712)

modules/ROOT/pages/constraints/index.adoc

@@ -8,7 +8,7 @@
 This section explains how to manage constraints used for ensuring data integrity.
 --
 
-
+[[types-of-constraint]]
 == Types of constraint
 
 The following constraint types are available:

modules/ROOT/pages/query-tuning/indexes.adoc

@@ -171,6 +171,12 @@ point.distance(n.prop, center) < = distance
 
 |===
 
+[NOTE]
+====
+As of Neo4j 5.11, the above set of predicates can be extended with the use of type constraints.
+For more information, see xref::query-tuning/indexes.adoc#extending-index-compatibility-with-type-constraints[Extending index compatibility with type constraints].
+====
+
 
 == TEXT indexes
 
@@ -188,7 +194,7 @@ However, other predicates are only used when it is known that the property is co
 * `n.prop = "string"`
 * `n.prop IN ["a", "b", "c"]`
 
-This means that a `TEXT` index is not able to solve e.g. `a.prop = b.prop`.
+This means that a `TEXT` index is not able to solve e.g. `a.prop = b.prop`, unless a type constraint also exists on the property.
 
 In summary, `TEXT` indexes support the following predicates:
 
@@ -233,6 +239,11 @@ CONTAINS
 
 |===
 
+[NOTE]
+====
+As of Neo4j 5.11, the above set of predicates can be extended with the use of type constraints, see xref::query-tuning/indexes.adoc#extending-index-compatibility-with-type-constraints[Extending index compatibility with type constraints].
+====
+
 In some cases, the system cannot determine whether an expression is of type string.
 
 For example when the compared value is a parameter:
@@ -248,7 +259,24 @@ Depending on how values that are not of type string should be treated, there are
 `MATCH (n:Label) WHERE $param STARTS WITH '' AND n.prop = $param`
 * If expressions which are not of type string should be converted to string, then wrapping these in `toString(<expression>)` is the right choice:
 `MATCH (n:Label) WHERE n.prop = toString($param)`
+* If it is known that the property is always of type `STRING`, then it's also possible to xref::query-tuning/indexes.adoc#extending-index-compatibility-with-type-constraints[add a type constraint to help the planner].
+
+[[extending-index-compatibility-with-type-constraints]]
+== Extending index compatibility with type constraints
+
+_This feature was introduced in Neo4j 5.11._
+
+For indexes that are compatible only with specific types (i.e. `TEXT` and `POINT` indexes), the planner needs to be able to deduce that a predicate will evaluate to `null` for non-compatible values.
+Since xref::constraints/index.adoc#types-of-constraint[type constraints] guarantee that a property is always of the same type, they can be used to extend the scenarios for which `TEXT` indexes and `POINT` indexes are compatible with a predicate.
+
+For example, if the property `prop` in the below query has been constrained to have type `STRING`, then a `TEXT` index can also be planned for the `IS NOT NULL` predicate:
+
+[source]
+----
+MATCH (n: Label) WHERE n.prop IS NOT NULL
+----
 
+Similarly, if the property had been constrained to have the type `POINT`, then a `POINT` index could have been used.
 
 == Index preference