-
Notifications
You must be signed in to change notification settings - Fork 64
New operators for Dynamic values #1360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 4 commits
f84991c
d8c377e
5aae3d4
ca3b3fe
14068d2
e1c1980
9e6fab9
6d17ba4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -639,10 +639,26 @@ RETURN relationshipType, count(r) AS relationshipCount | |||||
| [[dynamic-match-caveats]] | ||||||
| === Performance caveats | ||||||
|
|
||||||
| `MATCH` queries using dynamic values may not be as performant as those using static values. | ||||||
| This is because the xref:planning-and-tuning/execution-plans.adoc[Cypher planner] uses statically available information when planning queries to determine whether to use an xref:indexes/search-performance-indexes/index.adoc[index] or not, and this is not possible when using dynamic values. | ||||||
| `MATCH` queries that use dynamic values may not perform as well as those with static values. | ||||||
| Neo4j is actively working to improve the performance of these queries. | ||||||
| The table below outlines performance caveats for specific Neo4j versions. | ||||||
|
|
||||||
| As a result, `MATCH` queries using dynamic values cannot leverage xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead use the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. | ||||||
| .Neo4j versions and performance caveats | ||||||
| [%header,cols="a,5a"] | ||||||
| |=== | ||||||
| | Neo4j versions | Performance caveat | ||||||
|
|
||||||
| | 5.26 -- 2025.07 | ||||||
| | xref:planning-and-tuning/execution-plans.adoc[Cypher planner] not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. | ||||||
|
|
||||||
| | 2025.08 -- current | ||||||
| | Cypher planner is able to leverage leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically. | ||||||
|
||||||
| | Cypher planner is able to leverage leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically. | |
| | Cypher planner is able to leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid this is incorrect - the operator is called DynamicLabelNodeLookup!
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| It is not, however, able to indexes on property values. | |
| It is not, however, able to use indexes on property values. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| For example, `MATCH (n:$(Label) {foo: bar})` will not use any indexes on `n.foo`. | |
| For example, `MATCH (n:$(label) {foo: bar})` will not use any indexes on `n.foo` but might use a `DynamicNodeLabelLookup` on `$(label)`. |
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -740,12 +740,28 @@ RETURN greta.name AS name, labels(greta) AS labels, type(rel) AS relType, collec | |||||
| [[dynamic-merge-caveats]] | ||||||
| === Performance caveats | ||||||
|
|
||||||
| `MERGE` queries that use dynamic values may not be as performant as those using static values. | ||||||
| This is because the xref:planning-and-tuning/execution-plans.adoc[Cypher planner] uses statically available information when planning queries to determine whether to use an xref:indexes/search-performance-indexes/index.adoc[index] or not, and this is not possible when using dynamic values. | ||||||
| `MERGE` queries that use dynamic values may not perform as well as those with static values. | ||||||
| Neo4j is actively working to improve the performance of these queries. | ||||||
| The table below outlines performance caveats for specific Neo4j versions. | ||||||
|
|
||||||
| As a result, `MERGE` queries with dynamic values cannot leverage xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead use the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. | ||||||
| .Neo4j versions and performance caveats | ||||||
| [%header,cols="a,5a"] | ||||||
| |=== | ||||||
| | Neo4j versions | Performance caveat | ||||||
|
|
||||||
| | 5.26 -- 2025.07 | ||||||
| | xref:planning-and-tuning/execution-plans.adoc[Cypher planner] not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. | ||||||
|
||||||
| | xref:planning-and-tuning/execution-plans.adoc[Cypher planner] not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. | |
| | xref:planning-and-tuning/execution-plans.adoc[Cypher planner] is not able to leverage xref:indexes/search-performance-indexes/index.adoc[indexes] with xref:planning-and-tuning/operators/operators-detail.adoc#leaf-operators[index scans or seeks] and must instead utilize the xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-all-nodes-scan[`AllNodesScan`] operator, which reads all nodes from the node store and is therefore more costly. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| | Cypher planner is able to leverage leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically. | |
| | Cypher planner is able to leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes] when matching node labels and relationship types dynamically. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| It is not, however, able to indexes on property values. | |
| It is not, however, able to use indexes on property values. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| For example, `MERGE (n:$(Label) {foo: bar})` will not use any indexes on `n.foo`. | |
| For example, `MERGE (n:$(label) {foo: bar})` will not use any indexes on `n.foo` but might use a `DynamicNodeLabelLookup` on `$(label)`. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this "workaround" has been there before but I do not see that particular example helping:
If you have a static label Label, then
MERGE (n:Person:$($dynamicLabels) {name: "Greta Gerwig"})should plan a label scan on :Person and then add a filter on :$($dynamicLabels) without ON .... But if you want to add other labels depending on MATCH or MERGE behaviour, you will need to use the ON ... anyway.
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -22,6 +22,33 @@ Cypher 25 was introduced in Neo4j 2025.06 and can only be used on Neo4j 2025.06+ | |||||
| Features removed in Cypher 25 are still available on Neo4j 2025.06+ databases either by prepending a query with `CYPHER 5` or by having Cypher 5 as the default language for the database. | ||||||
| For more information, see xref:queries/select-version.adoc[]. | ||||||
|
|
||||||
| [[cypher-deprecations-additions-removals-2025.08]] | ||||||
| == Neo4j 2025.08 | ||||||
|
|
||||||
| === Updated in Cypher 25 | ||||||
|
|
||||||
| [cols="2", options="header"] | ||||||
| |=== | ||||||
| | Feature | ||||||
| | Details | ||||||
|
|
||||||
| a| | ||||||
| label:functionality[] | ||||||
| label:updated[] | ||||||
| [source, cypher] | ||||||
| ---- | ||||||
| PROFILE | ||||||
| WITH "Person" AS label | ||||||
| MATCH (people:$(label)) | ||||||
| RETURN people.name | ||||||
| ---- | ||||||
|
|
||||||
| | xref:clauses/match.adoc#dynamic-match[Dynamic labels and relationship types] can now leverage xref:indexes/search-performance-indexes/using-indexes.adoc#token-lookup-indexes[token lookup indexes]. | ||||||
|
||||||
| This is enables by the introduction of three new query plan operators: xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-node-label-lookup[`DynamicNodeLabelLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`]. | ||||||
|
||||||
| This is enables by the introduction of three new query plan operators: xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-node-label-lookup[`DynamicNodeLabelLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`]. | |
| This is enabled by the introduction of three new query plan operators: xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-node-label-lookup[`DynamicNodeLabelLookup`], xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-directed-relationship-type-lookup[`DynamicDirectedRelationshipTypeLookup`], and xref:planning-and-tuning/operators/operators-detail.adoc#query-plan-dynamic-undirected-relationship-type-lookup[`DynamicUndirectedRelationshipTypeLookup`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.