Did the change and the time went down to 20 seconds! Incredible.
Thanks for the hint! On Tuesday, 17 January 2017 07:59:52 UTC+1, [email protected] wrote: > > Yes, there are indexes. > > I was wondering about the shortest path but I need all the paths that end > at specific nodes, usually they will not be the shortests. I will try to > see if the results are the same with this modification. > > On Tuesday, 17 January 2017 03:31:59 UTC+1, Michael Hunger wrote: >> >> I presume you have an index / constraint on nodeType1.fullname AND >> nodeType1.name?! >> >> not sure why you do the pattern match first and only then the property >> lookup. >> >> What version are you using? in Neo4j 3.1 for the query below you should >> see much better performance: >> >> match (ea:nodeType1 {name:"something1"})<-[:maps_to*]-(eb:nodeType1) >> where eb.fullname starts with "something" >> with distinct ea, eb >> return ea.name <http://el.name/>, eb.name <http://et.name/>; >> >> I would also think that shortest-path is much more sensible here: >> >> match (ea:nodeType1 {name:"something1"}) >> match (eb:nodeType1) where eb.fullname starts with "something" >> match shortestPath( (ea)<-[:maps_to*]-(eb) ) >> with distinct ea, eb >> return ea.name <http://el.name/>, eb.name <http://et.name/>; >> >> On Mon, Jan 16, 2017 at 9:19 PM, <[email protected]> wrote: >> >>> Hi, I have a very expensive query that I'm trying to figure out how to >>> optimise. >>> >>> match (ea:nodeType1 {name:"something1"})<-[:maps_to*]-(eb:nodeType1) >>> with distinct ea, eb match (eb) where eb.fullname starts with >>> "something" return ea.name <http://el.name/>, eb.name <http://et.name/>; >>> >>> I've used the profiler and as expected the expand all is the most >>> expensive part of the operation >>> >>> +Filter | 128 | 334812480 | 669618290 | | >>> +VarLengthExpand(All) | 128 | 669618290 | 1494585385 | | >>> (ea)<-[:maps_to*]-(eb) >>> >>> >>> >>> I've used the profiler and brought down the running time from 3 hours to >>> 2,15. I then tried the enterprise version hoping that the query would use >>> the available processors but it used only one so I'm assuming that cypher >>> is not parallelizable. >>> >>> Is there some quick win to speed up a distinct path query or do I have >>> to write my own using the java api? >>> >>> p.s: the query might not compile as I've tried to summarise the gist of >>> the issue. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
