Conversation
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Config `supergraph.query_planning.experimental_parallelism` defaults to 1, but when set to something else `BridgeQueryPlannerPool` creates that many instances of `BridgeQueryPlanner` which in turn create a JS worker each. If config `experimental_query_planner_mode` is also set to `new` or `both` (current default is `legacy`), the each `BridgeQueryPlanner` would also unnecessarily create its own instance of the Rust `QueryPlanner` struct. Instead, a single `QueryPlanner` is now shared with `Arc`. Unlike JS workers, `QueryPlanner` only contains read-only data and can safely be shared between threads. This should reduce memory use when both `supergraph.query_planning.experimental_parallelism` and `experimental_query_planner_mode` are configured to non-default values.
- Also, strengthened the cycle detection assertion in the add_parent function.
… call (#5599) Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
Co-authored-by: bryn <bryn@apollographql.com> Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Fixes * Fix handling of `SubgraphEnteringTransition` which should skip `RootTypeResolution` edges. This fixes the issue with redundantly processing same edges over and over again. * Fix handling of `KeyResolution` which should compare whole selection sets of the conditions vs just the selections. * Ensures consistent order of child nodes when computing new key nodes * Add missing `self.on_modification()` when removing redundant edges * Returns false instead of throwing an error when calculating if new requires node is useless (i.e. return false if parent relation path is `None`) * Fix `PlanBuilder` trait to no longer swallow exceptions from query planning Co-authored-by: Duckki Oe <duckki.dev@gmail.com>
This reduces the compiled size of the `create_plugins` function, one of our largest ones for now
…number (#5758) Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
|
CI performance tests
|
|
only one merge conflict re: |
|
@lennyburdette when we cut 2.0-alpha.2, we're going to get a bunch of change notes from |
dylan-apollo
left a comment
There was a problem hiding this comment.
Approved, assuming we have a plan for the @cost stuff (composition & docs about connectors support)
| pub(crate) const COST_DIRECTIVE_NAME_IN_SPEC: Name = name!("cost"); | ||
| pub(crate) const COST_DIRECTIVE_NAME_DEFAULT: Name = name!("federation__cost"); | ||
|
|
||
| pub(crate) const LIST_SIZE_DIRECTIVE_NAME_IN_SPEC: Name = name!("listSize"); | ||
| pub(crate) const LIST_SIZE_DIRECTIVE_NAME_DEFAULT: Name = name!("federation__listSize"); |
There was a problem hiding this comment.
This means we have to make sure we merge in composition 2.9 (and update our composition to 2.10) before the next alpha release
| input_object_types: Vec<TypeInfo>, | ||
| } | ||
|
|
||
| fn get_original_directive_names( |
There was a problem hiding this comment.
Do the changes in this file do everything we need for expansion (i.e., we're not going to break anything)? Also, do we need to update our docs to state that we don't support these new ones?
There was a problem hiding this comment.
https://preview-docs.apollographql.com/graphos/connectors/limitations#interactions-with-graphos-router-features already mentions demand control, do you think we should be more specific about the directives?
There was a problem hiding this comment.
these changes look orthogonal, since cost/listSize are encoded specifically into the supergraph, as opposed to our general join__directive approach
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩