One of the powers of graph-based models is how well they represent interconnected data. When visualizing those models this power can lead to some unexpected draw backs; specifically pattern queries that are unexpectedly inefficient.
One common mistake is "overloading" a query. This is easy to do because the most common type of view is one showing all the "things" for a couple different element types. Notice below we have started a pattern query to view all the "things" in our city. Now say we also want to see the "other things". We have two options; we can add a new path or a new query:
Most of the time when someone builds a view like this they want to see all the "things" as well as all the "other things". We see most of our users choose the first option, leading to a pattern query that might look something like this:
Note that we have one query with three paths. This is actually a very inefficient way of setting up this query. The better way to do this would be to separate out each into it's own query, like this:
This will give us all the "things", all the "other things", and all the "somethings" in the most efficient (and fastest) query possible. It will pull in any connections between those elements (unless you've disabled "Automatically include edges between nodes") but will not limit the view to connected elements.
This begs the question: what's the difference between adding a path and adding a query and when should I use each? Think of each path as an interrelated set of elements. They're good for defining specific elements, sets of elements, or patterns of elements you want in a view. Everything in the path is "related" in some way, and everything in the path must be "met" for the elements to show up. Queries are "unrelated" sets of elements ("unrelated" in terms of the query, there could still be connections between those elements).
In the above example we wanted to see all of each of the three element types ("things", "other things", and "somethings"). We don't want to place any limitations (I'll come back to this in the next paragraph) so we are better off putting them in separate queries. While both pattern examples would produce the same view, the one with them all in the same path will take much longer to process because the query is looking at all the different combinations between the elements in the paths.
Say instead though, we wanted to see all the "things" that were connected to "other things", and only those (as opposed to seeing all the "things" and all the "other things" whether they are connected or not). This is where paths are needed:
Here we can see that our pattern is "things" with a "has" connection to "other things". This will show only the "things" and "other things" that are connected (and not those that are not).