Performance issues related to Neo4j path query - performance

Question

I have the following cypher query that basically is trying to find paths between the same set of nodes such that the paths returned contain all 5 specified relationships.
match p=(n)-[r*1..10]->(m)
where (m.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND (n.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND filter(x IN r where type(x)=~'.*isOfFormat.*')
AND filter(y IN r where type(y)=~'.*Processors.*')
AND filter(z IN r where type(z)=~'.*hasProducts.*')
AND filter(u IN r where type(u)=~'.*ProcessorFamilies.*')
AND filter(v IN r where type(v)=~'.*hasProductCategory.*')
return p;
The query I had above worked just fine and I got the paths I wanted. However, the execution time for the query was quite long. Below is some information about the query and the graph I used:
1) the graph contains 107,387 nodes and 226,468 relationships;
2) the size of the set of source(destination) nodes is 120; in other words, there are 120 strings in (n.URI IN ['x86_64/2#this', ... ,'/CSP52369']) and (m.URI IN ['x86_64/2#this', ...,'/CSP52369'];
The query execution time for the above query is 212,840 ms.
Then, in order to find nodes with the URI property faster, I use a label Uri for URI property and create an index on :Uri(URI). Then, I modified the query and the new query looks like:
match p=(n:URI)-[r*1..10]->(m:URI)
where (m.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND (n.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND filter(x IN r where type(x)=~'.*isOfFormat.*')
AND filter(y IN r where type(y)=~'.*Processors.*')
AND filter(z IN r where type(z)=~'.*hasProducts.*')
AND filter(u IN r where type(u)=~'.*ProcessorFamilies.*')
AND filter(v IN r where type(v)=~'.*hasProductCategory.*')
return p;
I ran the query again and the execution time was 5,841 ms. It did improve the performance a lot. However, I am not sure how the index helped here. I actually profiled both queries. Below are what I got.
The figure on the top/bottom is profiling result for the first/second query.
By comparing the two execution plans, I didn't see any operators related to index such as "NodeIndexSeek". Further, according to both plans, the system actually first computed all paths between n and m, then chose the ones to keep with the filter. Then, in this case, how would index help?
Can anybody help me clear up my doubts? Thanks in advance!!!

Answer 1

It seems your query runs with the RULE based optimizer while it should run with the cost based one? I hope you use the latest Neo4j version 2.3.1
I would also change your filter (which is not really a predicate) into:
You might need to add the index lookup hint:
WITH ["isOfFormat","Processors","hasProducts","ProcessorFamilies","hasProductCategory"] as types
MATCH p=(n:URI)-[rels*1..10]->(m:URI)
USING INDEX n:URI(URI)
USING INDEX m:URI(URI)
WHERE (m.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND (n.URI IN ['http://.../x86_64/2#this', ... ,'http://.../CSP52369'])
AND ALL(t in types WHERE ANY(r in rels WHERE type(r) = t))
RETURN p;
But you might be better off to express your concrete path as a concrete pattern with the relevant rel-types in between!!
Like Nicole suggested:
MATCH (n:URI)-[rels:isOfFormat|:Processors|:hasProducts|
:ProcessorFamilies|:hasProductCategory*..10]-(m:URI)
...