query planner you mean using reader3? or the tracer?

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

(def server-parser
  (p/parallel-parser
    {::p/env {::p/reader [p/map-reader
                          pc/parallel-reader
                          validate-connect-key-reader
                          pc/open-ident-reader
                          p/env-placeholder-reader]
              ::p/placeholder-prefixes #{">"}}
     ::p/mutate pc/mutate-async
     ::p/plugins [(pc/connect-plugin {::pc/register (concat res-i/resolvers engine/resolvers sponsor/resolvers)})
                  p/error-handler-plugin
                  p/trace-plugin]}))

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?

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

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

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?