diff --git a/pages/database-management/monitoring.mdx b/pages/database-management/monitoring.mdx index c596a0d3d..e967f5d25 100644 --- a/pages/database-management/monitoring.mdx +++ b/pages/database-management/monitoring.mdx @@ -264,6 +264,7 @@ JSON endpoint and `SHOW METRICS INFO` use different names — see | memgraph\_active\_edge\_type\_indices | Gauge | Number of active edge-type indexes. | | memgraph\_active\_edge\_type\_property\_indices | Gauge | Number of active edge-type-property indexes. | | memgraph\_active\_edge\_property\_indices | Gauge | Number of active edge-property indexes. | + | memgraph\_active\_vertex\_property\_indices | Gauge | Number of active vertex-property indexes. | | memgraph\_active\_point\_indices | Gauge | Number of active point indexes. | | memgraph\_active\_text\_indices | Gauge | Number of active text indexes on vertices. | | memgraph\_active\_text\_edge\_indices | Gauge | Number of active text indexes on edges. | @@ -321,6 +322,7 @@ used. | memgraph\_scan\_all\_by\_edge\_property\_value\_operator\_total | Counter | | memgraph\_scan\_all\_by\_edge\_property\_range\_operator\_total | Counter | | memgraph\_scan\_all\_by\_edge\_id\_operator\_total | Counter | + | memgraph\_scan\_all\_by\_vertex\_property\_operator\_total | Counter | | memgraph\_scan\_all\_by\_point\_distance\_operator\_total | Counter | | memgraph\_scan\_all\_by\_point\_withinbbox\_operator\_total | Counter | | memgraph\_expand\_operator\_total | Counter | diff --git a/pages/database-management/server-stats.mdx b/pages/database-management/server-stats.mdx index 86bbec23e..51a8c2c19 100644 --- a/pages/database-management/server-stats.mdx +++ b/pages/database-management/server-stats.mdx @@ -230,6 +230,7 @@ are reported in microseconds. | "ActiveEdgeTypePropertyIndices" | "Index" | "Gauge" | 0 | | "ActiveLabelIndices" | "Index" | "Gauge" | 6 | | "ActiveLabelPropertyIndices" | "Index" | "Gauge" | 18 | +| "ActiveVertexPropertyIndices" | "Index" | "Gauge" | 0 | | "ActivePointIndices" | "Index" | "Gauge" | 0 | | "ActiveTextIndices" | "Index" | "Gauge" | 0 | | "ActiveTextEdgeIndices" | "Index" | "Gauge" | 0 | @@ -293,6 +294,7 @@ are reported in microseconds. | "ScanAllByIdOperator" | "Operator" | "Counter" | 0 | | "ScanAllByLabelOperator" | "Operator" | "Counter" | 0 | | "ScanAllByLabelPropertiesOperator" | "Operator" | "Counter" | 0 | +| "ScanAllByVertexPropertyOperator" | "Operator" | "Counter" | 0 | | "ScanAllByPointDistanceOperator" | "Operator" | "Counter" | 0 | | "ScanAllByPointWithinbboxOperator" | "Operator" | "Counter" | 0 | | "ScanAllOperator" | "Operator" | "Counter" | 0 | diff --git a/pages/fundamentals/indexes.mdx b/pages/fundamentals/indexes.mdx index 63e5c9d58..ab20bfbf6 100644 --- a/pages/fundamentals/indexes.mdx +++ b/pages/fundamentals/indexes.mdx @@ -477,6 +477,53 @@ not yet supported. +### Global vertex property index + + + +This index supports non-blocking creation: reads continue without interruption, +while writes are briefly paused. For more information, see the [concurrent index +creation](#concurrent-index-creation). + + + +A label-property index requires you to know the label up front. But sometimes +you just want to find a node by a property, say `uuid`, regardless of what +labels the node has. Global vertex-property indices allow you to do exactly +this. For example, to create an index on all nodes with a `uuid` property: + +```cypher +CREATE GLOBAL INDEX ON :(uuid); +``` + +Once created, queries that search by that property can use the index +automatically: + +```cypher +MATCH (n) WHERE n.uuid = "abc-123" RETURN n; +MATCH (n {uuid: "abc-123"}) RETURN n; +``` + +The planner also considers this index as a fallback when a query specifies a +label but no matching label-property index exists. For example, if there is no +index on `:Person(uuid)` but a global index on `uuid` exists, +`MATCH (n:Person {uuid: "abc-123"}) RETURN n` can use the global index and +filter by label afterwards. + + + +When both a label-property index and a global vertex property index could serve +a query, the planner picks whichever has the lower estimated cardinality. In +practice this usually means the label-property index wins, since it's scoped to +a single label. + + + +To drop the index: +```cypher +DROP GLOBAL INDEX ON :(uuid); +``` + ### Edge-type index @@ -696,7 +743,8 @@ memgraph> MATCH (n:Person) WHERE n.name =~ ".*an$" RETURN n.name; ## Show created indexes To see all the information on the label, label-property, edge-type, edge-type -property, point indexes and vector indexes, run the following query: +property, global vertex property, global edge property, point indexes and vector +indexes, run the following query: ```cypher SHOW INDEX INFO; @@ -739,6 +787,10 @@ DROP INDEX ON :Label(property); DROP INDEX ON :Label(property1, property2); ``` +```cypher +DROP GLOBAL INDEX ON :(property_name); +``` + ```cypher DROP EDGE INDEX ON :EDGE_TYPE; ``` @@ -760,8 +812,8 @@ DROP POINT INDEX ON :Label(property); The `DROP ALL INDEXES` clause allows you to delete all indices in your database in a single operation. This includes all types of indices: label indices, label-property indices, edge type indices, edge type-property indices, global -edge indices, point indices, text indices, vector indices, and vector edge -indices. +vertex property indices, global edge property indices, point indices, text +indices, vector indices, and vector edge indices. ```cypher DROP ALL INDEXES; @@ -956,6 +1008,10 @@ USING INDEX :Label(property) ...; USING INDEX :Label(property1, property2) ...; ``` +```cypher +USING INDEX :(property) ...; +``` + It is also possible to specify multiple hints separated with comma. In that case, the planner will apply the first hint that is applicable for a given match. @@ -1008,8 +1064,8 @@ b_1$, or $a_1 = b_1$ and $a_2 < b_2$. Memgraph supports **(almost) fully concurrent index creation** for all skiplist-based indices, including label, label-property, composite, edge-type, -edge-type property, and global edge property, with minimal impact on -performance. +edge-type property, global edge property, and global vertex property, with +minimal impact on performance. The three-phase implementation begins with a brief **registration phase** that requires `READ ONLY` access. This ensures that all pending write transactions