The next thing to look at is rule #4 ‘Start your MATCH patterns at the lowest cardinality identifier you can’. We can work out the cardinality of an identifier by prefixing the query with ‘PROFILE’ and analysing the output:

The main thing to look at is the value of _rows. Here it starts at 523 (the number of nodes labelled with ‘Player’) and then explodes out to 10394 after evaluating the first MATCH expression. The second MATCH expression takes us back down to 5192 which gets further reduced to 503 after we group by player.

An alternative to starting our query from players is to start from games instead and a COUNT based query shows us that this will result in our query starting out with slightly less rows:

…we can see that the number of nodes that SUM had to deal with was reduced from 5192 to 394 which explains why using a WHERE to lookup a property is slightly cheaper in this case. If using a WHERE had reduced the number of nodes more marginally it wouldn’t be worthwhile.

Overall we’ve taken the time it takes for 5 runs of the query down from an average of 689 milliseconds to 236 milliseconds so thank you Wes!