@Damon My understanding is that the DQL parser is not capable of optimizing queries in the manner in which I recommended zedzhu try. Take a look at this comparison of query.Result objects returned from DQL parsing both of these queries. The results of original query is on the left and the query I recommended to zedzhu is on the right.
Link: JSONCompare - The Advanced JSON Linting & Comparison Tool
Note the chain of QueryVars starting at 383 (right side). It’s my understanding that this forces query processing to build subsequent, dependent subgraphs using the parameters defined in each query step. This reduces the first subgraph to just the first query results. Whereas the original, slower query gloms them all together in “one query” (and subsequently visits all uids in the query space).
Whenever I query a large graph, I always approach it by trying to find the smallest set (subgraph) first. Of course that requires an understanding of the composition of one’s graph, but hey, there’s no free lunch.
An original team member wrote some thoughts on a query planner that I think might address some of the issues and is an interesting read: Query Planner - #3 by chewxy