-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the query planner options to the query plan cache key #5100
Conversation
This comment has been minimized.
This comment has been minimized.
CI performance tests
|
…nges when the query plan gets updated.
Rename tests to be in line with other tests in this file
I added some testing for this which meant extending the integration test runner a little. I'm not massively keen on the way that we obtain the config for the query planners. Once the rust query planner is hashable maybe we could consider implementing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reviewed some softer bits and requested changes around them on account of looking for answers to my questions, but I will leave the rest of the review to others for now. Happy to revisit.
Co-authored-by: Jesse Rosenberger <git@jro.cc>
Skip redis tests on CI for anything other than x86_64
"plan:{}:{}:{}:{}", | ||
FEDERATION_VERSION, self.hash, operation, metadata, | ||
"plan:{}:{}:{}:{}:{}", | ||
CACHE_KEY_VERSION, FEDERATION_VERSION, self.hash, operation, metadata, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unrelated to this particular PR, but it took me a while to understand that operation
is a hash of self.operation
, which is actually an operation name.
Also, self.hash
is hash of query and relevent parts of schema, but taking into account only operation matching operation_name
.
At the same time, self.hash
doesn't include a hash of "operation_name" itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also self.metadata
is actually "authorization metadata".
P.S. Same as the previous comment, this is unrelated to this PR.
Just comments for others to also understand what is happening in this code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see this refactored and keys become self describing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When/where does this change get itemized/made?
hasher.update(&serde_json::to_vec(&self.sdl).expect("serialization should not fail")); | ||
hasher.update([self.introspection as u8]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is introspection added here but not in the Hash implementation below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch: 43ccd9d
I am wondering though why we are using a manual implementation of Hash
rather than using derive? There seems to be nothing special about this structure that would warrant a custom impl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have to dig it up, but I think there was something in the key that could not implement Hash
in the past
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we figure that out, is there somewhere we could add a comment to make that more intuitive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't need a custom implementation now let's remove it and use derive. That way we don't have to worry about it in the future. If we do eventually need a custom version would need to comment and possibly fuzz test.
Co-authored-by: Jesse Rosenberger <git@jro.cc>
thank you all for the feedback, I will make another pass today or tomorrow to fix up the small issues. @BrynCooke do you want to see the hash prefxies in this PR or in a follow up? I plan to make another PR right after to fix other things, like removing the JSON usage when possible |
@Geal Happy for the key change to be a follow up. |
@abernix can we merge this? |
@Geal Does this completely supersede @fotoetienne's #5094? If so, curious if @xuorig / @fotoetienne could take a look. |
My previous review is no longer relevant based on many new changes.
yes it supersedes that PR |
"plan:{}:{}:{}:{}", | ||
FEDERATION_VERSION, self.hash, operation, metadata, | ||
"plan:{}:{}:{}:{}:{}", | ||
CACHE_KEY_VERSION, FEDERATION_VERSION, self.hash, operation, metadata, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this PR: Why are operation
and metadata
separate vs combined in the same hasher?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that was a way to see how many variants there can be in cache for a single query
follow up issue with the fixes we discussed: #5160 |
Query planner options can affect the way the query plan is generated, so when they change, we should not reuse query plans generated with the previous options. To that end, we are now adding those options to the query plan cache key Co-authored-by: Stephen Spalding <sspalding@netflix.com> Co-authored-by: bryn <bryn@apollographql.com> Co-authored-by: Bryn Cooke <BrynCooke@gmail.com> Co-authored-by: Jesse Rosenberger <git@jro.cc>
Fix #5093
Some query plan options can result in incompatible generated plans if they are enabled or disabled, so we must take them into account in the cache key, otherwise a router might get a plan from the cache that does not match its configuration.
We cannot cover the entire apollo-federation config in the hash for now, this will have to be done as a follow up
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. ↩