Neo4j query optimization

Question

at Neo4j Graph Academy (http://neo4j.com/graphacademy/online-course/) I read at "(L2) -- (Aggregation)" section:

Oftentimes you're interested in the top-n results, which result from a count aggregation. This is achieved by counting first and the ordering the results in a DESCending manner and then LIMITing the results by the top n. If we would be interested in the top ten actors, who acted in the most movies, the query would look like this.

MATCH (a:Person)-[:ACTED_IN]->(m)
RETURN a.name, count(m)
ORDER BY count(m) DESC
LIMIT 10;

However, I'm wondering if it is clever enough to not calculate multiple times the count(m) there, that is if a syntax similar to the following is better:

MATCH (a:Person)-[:ACTED_IN]->(m)
RETURN a.name, count(m) AS c
ORDER BY c DESC
LIMIT 10;

Answer 1

The answer is that the query plans are exactly identical, and one is not better than the other.

Using the PROFILE keyword before the query, you can ask neo4j how it would execute each query. So don't take my word for it, profile both queries and see if the plans are any different. If they're not, then the execution of both will be the same.

Here's what the query profile looks like:

I think the count() is happening in EagerAggregation, and it's happening prior to the top operation irrespective of how you express that count.

Cypher query optimization is making progress these days. With version 2.2, there's a new cost based planner in there. I don't know if this particular query is implicated in the new cost-based planner code (actually probably not) but the bigger point here is that if a query language's optimizer is working well, then there really shouldn't be any difference between those two queries. See, if two queries are semantically equivalent, then the optimizer's job is always to re-write your query into the fastest-executing version of itself that's semantically equivalent.

This provides some leeway for you to write less than perfect cypher but still get good results. In general, I wouldn't overcomplicate your queries to speed them up until you have a real performance problem ("premature optimization is the root of all evil"). If you want to know whether a different formulation of a query would even help, use PROFILE.