From d009321d12c822f2b989ba95537c3cd16c293f59 Mon Sep 17 00:00:00 2001 From: Gustav Hedengran Date: Thu, 7 Sep 2023 16:16:59 +0200 Subject: [PATCH] Type constraint index tuning (#712) --- modules/ROOT/pages/constraints/index.adoc | 2 +- modules/ROOT/pages/query-tuning/indexes.adoc | 30 +++++++++++++++++++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/constraints/index.adoc b/modules/ROOT/pages/constraints/index.adoc index 10507a2e1..1e8761c8b 100644 --- a/modules/ROOT/pages/constraints/index.adoc +++ b/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: diff --git a/modules/ROOT/pages/query-tuning/indexes.adoc b/modules/ROOT/pages/query-tuning/indexes.adoc index 920ea8727..46305cb51 100644 --- a/modules/ROOT/pages/query-tuning/indexes.adoc +++ b/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()` 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