Fork me on GitHub
λustin f(n)20:04:55

How can I debug the query planner, and what kinds of things confuse it? I am starting to get the query planner taking the vast majority of the query time


query planner you mean using reader3? or the tracer?

λustin f(n)22:04:02

Not sure, but I am trying to debug a long query, so I am requesting a :com.wsscode.pathom/trace along with my request. I am using the following setup

λustin f(n)22:04:04

(def server-parser
    {::p/env {::p/reader [p/map-reader
              ::p/placeholder-prefixes #{">"}}
     ::p/mutate pc/mutate-async
     ::p/plugins [(pc/connect-plugin {::pc/register (concat res-i/resolvers engine/resolvers sponsor/resolvers)})

λustin f(n)22:04:35

And the 'compute-plan' step is coming back as nearly 30 seconds for my particular query


ok, the first guess would be too many edges, 30 seconds is really long time, are you in a case where there are a lot of mutiple input requirements on the resolvers?

λustin f(n)22:04:16

So, is it expected that things will start taking a long time if my graph starts sprawling too much?

λustin f(n)22:04:38

And yes, there are probably 4+ places in this query where it uses a multiple-input resolver


yeah, the planner on reader2 is quite inefficient around multiple inputs, because it does a cartesian product of branches, that means the number of generated paths multiply quickly when you have many multiple inputs combined


that said, I believe (still need to measure in the real world) that the new planner handles those much better


I suggest you try the alpha releases, and use serial-parser with reader3 (instead of parallel-reader)


and please let me know how that goes, I expect the plan computation to be considerably faster

λustin f(n)21:04:15

It simply gave me a quick 'not-found' instead


I would be interest to see a reproduction of that, can you simple a demo failing case?