merge dev into next (again) #6479
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
) The router's native, Rust-based, query planner is now generally available and enabled by default. The native query planner achieves better performance for a variety of graphs. In our tests, we observe: * 10x median improvement in query planning time (observed via `apollo.router.query_planning.plan.duration`) * 2.9x improvement in router’s CPU utilization * 2.2x improvement in router’s memory usage > Note: you can expect generated plans and subgraph operations in the native query planner to have slight differences when compared to the legacy, JavaScript-based query planner. We've ascertained these differences to be semantically insignificant, based on comparing ~2.5 million known unique user operations in GraphOS as well as comparing ~630 million operations across actual router deployments in shadow mode for a four month duration. The native query planner supports Federation v2 supergraphs. If you are using Federation v1 today, see our migration guide on how to update your composition build step and subgraph changes are typically not needed. The legacy, JavaScript, query planner is deprecated in this release, but you can still switch back to it if you are still using Federation v1 supergraph: ```yaml experimental_query_planner_mode: legacy ``` > Note: The subgraph operations generated by the query planner are not guaranteed consistent release over release. We strongly recommend against relying on the shape of planned subgraph operations, as new router features and optimizations will continuously affect it. Co-authored-by: Chandrika Srinivasan <chandrikas@users.noreply.github.com> Co-authored-by: Edward Huang <edward.huang@apollographql.com> Co-authored-by: Shane Myrick <mail@shanemyrick.com>
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
As per docs suggestion, remove this changeset
If user explicitly opt-out of the `@defer` support, deferred queries will be rejected by the router with GraphQL validation error (unknown directive). It is not possible to plan a query with a `@defer` in it when defer support is disabled so we can simplify this logic.
garypen
requested review from
dariuszkuc,
sachindshinde,
goto-bus-stop,
SimonSapin,
lrlna,
TylerBloom,
duckki and
a team
as code owners
✅ Docs Preview ReadyNo new or changed pages found. |
|
CI performance tests
|
goto-bus-stop
approved these changes
Dec 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pick up the changes from
devafter yesterday's reconciliation frommain.