# Best practices for queries that can take hours to complete **URL:** \ **Category:** Cypher\ **Created:** [November 26, 2020, 3:21pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666 "2020-11-26T15:21:18Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![marek\_kasle\_na](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/marek_kasle_na/32/14849_2.png) [@marek\_kasle\_na](https://community.neo4j.com/u/marek_kasle_na)\ **Post date:** [November 26, 2020, 3:21pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/1 "2020-11-26T15:21:18Z")
What is the right way to execute and get results from a query that takes hours to process? Or is just Neo4j not built to do such things? Or is there some hidden timeout limit that silently kills such queries? Or do I need the enterprise edition? Obviously running the query in browser and waiting for the result is out of the question. I had some success with wrapping the query into apoc.export.cypher.query() and executing it locally through cypher-shell running in background using '&' on Linux as suggested here [Cypher-Shell - how to run testquery.cypher in background](https://community.neo4j.com/t/cypher-shell-how-to-run-testquery-cypher-in-background/16496). Works for queries taking e.g. 20 minutes but more demanding queries seems to just die silently without leaving any trace in the logs. ---
**Author:** ![lju](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/lju/32/12574_2.png) [@lju](https://community.neo4j.com/u/lju)\ **Post date:** [November 27, 2020, 12:24pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/2 "2020-11-27T12:24:14Z")
Hi @marek_kasle_na There are many things that may cause a query to take a long time to run. Usually, some query optimisation and/or model refactoring can make huge impacts on this. Are you able to share your queries/talk about what optimisations you have done to them? Also, how much memory have you configured for the queries to run? Cheers, Lju ---
**Author:** ![clem](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/clem/32/4364_2.png) [@clem](https://community.neo4j.com/u/clem)\ **Post date:** [November 27, 2020, 5:22pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/3 "2020-11-27T17:22:33Z")
see the very good video: [![](https://us1.discourse-cdn.com/flex021/uploads/neo4jcommunity/original/2X/1/1188473e6e6695ecde2519b34e1159ab063ea634.jpeg "Tuning Cypher") ](https://www.youtube.com/watch?v=QnozzFP_fPo) which also points to: - [Execution plans - Cypher Manual](https://neo4j.com/docs/cypher-manual/current/execution-plans/) - [Tag performance - Knowledge Base](https://neo4j.com/developer/kb/tags/performance/) - [Query tuning - Cypher Manual](https://neo4j.com/docs/cypher-manual/current/query-tuning/) (especially part 2.) Not knowing specifics of your problem, here are some random ideas (stabs in the dark and I don't mean to insult your intelligence if you already know about these...): - Make sure you have [indexes](https://neo4j.com/docs/cypher-manual/current/administration/indexes-for-search-performance/) created for things that you are filtering on. Also potentially useful is **composite indexes** : [Composite Indexes in Neo4j 4.0 | Max De Marzi](https://maxdemarzi.com/2020/02/19/composite-indexes-in-neo4j-4-0/#more-5696) - Use integers or floats where possible (e.g. `toInteger()` and `toFloat()` and store them in the DB before doing the query) - Avoid cartesian products: Instead of `MATCH(a:A),(b:B) WHERE ...` use `MATCH(a:A) MATCH(b:B) WHERE...` - Use Labels in your queries. `MATCH(a)-[r]-> ...` is more expensive than `MATCH(a:A)-[r:R]->...` - Try parallelism: [Parallel Cypher Execution - APOC Extended Documentation](https://neo4j.com/labs/apoc/4.2/cypher-execution/parallel/) (I haven't tried it myself, so I'm not sure how it works exactly.) - figure out how to winnow down the possible matches as much as possible and as soon as possible in the query. - I suspect this is true: take advantage of NULL values instead of setting things to empty strings or 0. I believe that property looks will go faster if Neo4J sees that there is no property, instead of looking up the property and then getting its value to do the comparison. E.g. `length(a.property)=0` is more expensive than `a.property IS NULL` but I don't know how much more expensive it is. I hope this helps. If you could show us your query (along with some statistics: `call apoc.meta.stats` and `:schema`) perhaps we could better be able to help you. ---
**Author:** ![marek\_kasle\_na](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/marek_kasle_na/32/14849_2.png) [@marek\_kasle\_na](https://community.neo4j.com/u/marek_kasle_na)\ **Post date:** [November 27, 2020, 6:42pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/4 "2020-11-27T18:42:25Z")
Thank you both for valuable tips. Now lets say, hypothetically, that the query is as optimized as it can be and I am perfectly ok with it running for 2 hours before I get the result because it is some complex computation or extraction of a large subgraph that simply takes a lot of time. Now is there some obstacle, like some default dbms.transaction.timeout that will stop me from getting the result from Neo4j? ---
**Author:** ![clem](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/clem/32/4364_2.png) [@clem](https://community.neo4j.com/u/clem)\ **Post date:** [November 27, 2020, 11:27pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/5 "2020-11-27T23:27:53Z")
Another link on query optimizations: > **[Cypher Query Optimisations](https://medium.com/neo4j/cypher-query-optimisations-fe0539ce2e5c)** > > In this post I explain common issues with query performance in Neo4j and how you may solve them using the Query Log Analyser tool. I wasn't clearly your question on time out... But if you set the timeout to 0, it won't timeout: > **[Manage transactions - Operations Manual](https://neo4j.com/docs/operations-manual/current/monitoring/transaction-management/#transaction-management-transaction-timeout)** > > This section describes facilities for transaction management. ---
**Author:** ![clem](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/clem/32/4364_2.png) [@clem](https://community.neo4j.com/u/clem)\ **Post date:** [November 29, 2020, 2:55am UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/6 "2020-11-29T02:55:53Z")
I found another interesting video. What is very interesting is at minute 15:30. If your query has TWO things that you are filtering and that has an index, then it's better to force Neo4J to use both indexes. **I'm surprised by this!**. (I tried this with version 4.2) Their example using the Movie DB. Instead of this: ```auto PROFILE MATCH p = (p1:Person)-[:ACTED_IN*6]-(p5:Person) WHERE p1.name='Tom Cruise' and p5.name='Kevin Bacon' RETURN [n in nodes(p) | coalesce(n.title, n.name)] ``` do this: ```auto PROFILE MATCH p = (p1:Person)-[:ACTED_IN*6]-(p5:Person) USING INDEX p1:Person(name) USING INDEX p5:Person(name) WHERE p1.name='Tom Cruise' and p5.name='Kevin Bacon' RETURN [n in nodes(p) | coalesce(n.title, n.name)] ``` [![](https://us1.discourse-cdn.com/flex021/uploads/neo4jcommunity/original/3X/d/d/dda5148404b21dfa2587dbb4e1a9842d58d5683d.jpeg "Lesser Known Features in Cypher") ](https://www.youtube.com/watch?v=BN5T8IimB78) ---
**Author:** ![lju](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/lju/32/12574_2.png) [@lju](https://community.neo4j.com/u/lju)\ **Post date:** [December 4, 2020, 12:23pm UTC](https://community.neo4j.com/t/best-practices-for-queries-that-can-take-hours-to-complete/29666/7 "2020-12-04T12:23:54Z")
In this hypothetical situation, provided that you've managed your query in such a way that the memory load is controlled, yes, you could set configuration in such a way to ensure the query runs for as long as it needs to