I'm experiencing an unexpected performance issue with a simple Neo4j query.
The following query runs very slowly because it tries to find all relations of Language (there is only one relation with Article):
PROFILE MATCH (article:Article)-[r:IN_LANGUAGE]->(language:Language)
WHERE elementId(article) = '4:a5ad2f22-47ff-4fcc-a208-358646d5b3ec:261210970'
AND elementId(language) = '4:a5ad2f22-47ff-4fcc-a208-358646d5b3ec:1074513'
RETURN r
However, using an indexed property, it does what I would expect:
PROFILE MATCH (article:Article)-[r:IN_LANGUAGE]->(language:Language)
WHERE article.uuid = '57686315-e27e-42bd-bbef-3736f9d896f9'
AND language.uuid = 'af8bd5c02b8211e8b26f020bc29461c8'
RETURN r
Unfortunately, my use case requires the use of node element IDs.
Does anyone know why this is happening, and if I could optimize this query? I'm guessing internally elementId() or id() works differently than indexed properties, but somehow this behavior looks very weird to me.
I don't think elementID is hashed the same way as an index and would suggest you figure a way of migrating away from elementID() or you might start having weird behaviours.
Quote:
There are important considerations to bear in mind when using elementId():
Every node and relationship is guaranteed an element ID. This ID is unique among both nodes and relationships across all databases in the same DBMS within the scope of a single transaction. However, no guarantees are given regarding the order of the returned ID values or the length of the ID STRINGvalues. Outside of the scope of a single transaction, no guarantees are given about the mapping between ID values and elements. 2. Neo4j reuses its internal IDs when nodes and relationships are deleted. Applications relying on internal Neo4j IDs are, as a result, brittle and can be inaccurate. It is therefore recommended to use application-generated IDs.
