Query planner pool

[o0Ignition0o]

This is the place to discuss the experimental query planner pool feature seen in the documentation here, added in #4897.

Here we will be able to compare benchmarks, tuning, and listen to feedback.

You can configure query planner pools with the supergraph.query_planner.experimental_available_parallelism option:

supergraph:
  query_planner:
    experimental_available_parallelism: auto # number of available cpus

Its value is the number of query planners that run in parallel, and its default value is 1. You can set it to the special value auto to automatically set it equal to the number of available CPUs.

[samuelAndalon]

Will this create a N deno runtimes or N workers ?

i have create this feature request
#4966

Where i'm proposing the usage of a coprocessor for query planning, i ran some benchmarks of building query plans with Bun and the results are promising.

My main take here is that for an IO application, the less CPU usage the better, query planner can be done in a separate entity, such a sidecar. query planning is by nature synchronous, so in terms of CPU it will always better to wait for an IO result instead of constructing a query plan that could cause CPU usage to increase, this is specially harmful during supergraph updates.