You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dynamic resolver could be further optimize by the planner to avoid unnecessary call to external services.
They tend to be used to talk to external services (DB, graphql, API) round trip to such services is usually slow so they should be merged as much as possible to batch request.
Here's a proposed algo for the planer to merge dynamic revolvers:
From a dynamic resolver node that is present multiple time in the graph.
Walk the graph towards the root and find a branching node where the node to be moved.
If that node already has the same dynamic resolver, merge them.
Hi @JohanCodinha! Sorry for the long delay, I'm getting back to this now. I like the idea, can you provide me some test examples that can demonstrate the improvement of these optimizations?
Dynamic resolver could be further optimize by the planner to avoid unnecessary call to external services.
They tend to be used to talk to external services (DB, graphql, API) round trip to such services is usually slow so they should be merged as much as possible to batch request.
Here's a proposed algo for the planer to merge dynamic revolvers:
From a dynamic resolver node that is present multiple time in the graph.
Walk the graph towards the root and find a branching node where the node to be moved.
If that node already has the same dynamic resolver, merge them.
The text was updated successfully, but these errors were encountered: