-
Notifications
You must be signed in to change notification settings - Fork 275
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
warm up the query plan cache with persisted queries #3829
Merged
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
@Geal, please consider creating a changeset entry in |
CI performance tests
|
bnjjj
approved these changes
Sep 15, 2023
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.
Just missing a changelog
I think we'll make one changelog entry for all the warmup improvements |
if they are not used very often, they will be evicted from the cache sooner
glasser
reviewed
Sep 18, 2023
bnjjj
reviewed
Sep 19, 2023
glasser
added a commit
that referenced
this pull request
Sep 10, 2024
In #3829 we taught router to use the PQ list to prewarm the query planner cache when reloading its schema. In #5340 we gave it the experimental option to do the same thing at startup. Now we are allowing you to turn off the on-reload prewarm. Because the PQ list does not have metadata to tell the Router which PQs have been used recently, if you have a large PQ list then the on-reload prewarm can slow down schema updates noticeably, and it may not provide much value over prewarming based on the contents of the in-memory QP cache itself. We keep the same defaults, but let you turn off the on-reload prewarm with: ``` persisted_queries: experimental_prewarm_query_plan_cache: on_reload: false ``` Previously, `persisted_queries.experimental_prewarm_query_plan_cache` was a boolean; a migration moves this boolean to `persisted_queries.experimental_prewarm_query_plan_cache.on_startup`. (`on_startup` defaults to false and `on_reload` defaults to true.) This migration uses a `type: change` action. No such actions existed in the codebase and the implementation appeared to be buggy: there is no top-level `==` operator (or top-level operators at all) in JSONPath. This PR fixes the implementation of `type: change` to use the `[?(@.x == y)]` filter syntax which does appear to work (as tested by the migration tests for the new migration).
6 tasks
glasser
added a commit
that referenced
this pull request
Sep 10, 2024
In #3829 we taught router to use the PQ list to prewarm the query planner cache when reloading its schema. In #5340 we gave it the experimental option to do the same thing at startup. Now we are allowing you to turn off the on-reload prewarm. Because the PQ list does not have metadata to tell the Router which PQs have been used recently, if you have a large PQ list then the on-reload prewarm can slow down schema updates noticeably, and it may not provide much value over prewarming based on the contents of the in-memory QP cache itself. We keep the same defaults, but let you turn off the on-reload prewarm with: ``` persisted_queries: experimental_prewarm_query_plan_cache: on_reload: false ``` Previously, `persisted_queries.experimental_prewarm_query_plan_cache` was a boolean; a migration moves this boolean to `persisted_queries.experimental_prewarm_query_plan_cache.on_startup`. (`on_startup` defaults to false and `on_reload` defaults to true.) This migration uses a `type: change` action. No such actions existed in the codebase and the implementation appeared to be buggy: there is no top-level `==` operator (or top-level operators at all) in JSONPath. This PR fixes the implementation of `type: change` to use the `[?(@.x == y)]` filter syntax which does appear to work (as tested by the migration tests for the new migration).
glasser
added a commit
that referenced
this pull request
Sep 10, 2024
In #3829 we taught router to use the PQ list to prewarm the query planner cache when reloading its schema. In #5340 we gave it the experimental option to do the same thing at startup. Now we are allowing you to turn off the on-reload prewarm. Because the PQ list does not have metadata to tell the Router which PQs have been used recently, if you have a large PQ list then the on-reload prewarm can slow down schema updates noticeably, and it may not provide much value over prewarming based on the contents of the in-memory QP cache itself. We keep the same defaults, but let you turn off the on-reload prewarm with: ``` persisted_queries: experimental_prewarm_query_plan_cache: on_reload: false ``` Previously, `persisted_queries.experimental_prewarm_query_plan_cache` was a boolean; a migration moves this boolean to `persisted_queries.experimental_prewarm_query_plan_cache.on_startup`. (`on_startup` defaults to false and `on_reload` defaults to true.) This migration uses a `type: change` action. No such actions existed in the codebase and the implementation appeared to be buggy: there is no top-level `==` operator (or top-level operators at all) in JSONPath. This PR fixes the implementation of `type: change` to use the `[?(@.x == y)]` filter syntax which does appear to work (as tested by the migration tests for the new migration).
glasser
added a commit
that referenced
this pull request
Sep 10, 2024
In #3829 we taught router to use the PQ list to prewarm the query planner cache when reloading its schema. In #5340 we gave it the experimental option to do the same thing at startup. Now we are allowing you to turn off the on-reload prewarm. Because the PQ list does not have metadata to tell the Router which PQs have been used recently, if you have a large PQ list then the on-reload prewarm can slow down schema updates noticeably, and it may not provide much value over prewarming based on the contents of the in-memory QP cache itself. We keep the same defaults, but let you turn off the on-reload prewarm with: ``` persisted_queries: experimental_prewarm_query_plan_cache: on_reload: false ``` Previously, `persisted_queries.experimental_prewarm_query_plan_cache` was a boolean; a migration moves this boolean to `persisted_queries.experimental_prewarm_query_plan_cache.on_startup`. (`on_startup` defaults to false and `on_reload` defaults to true.) This migration uses a `type: change` action. No such actions existed in the codebase and the implementation appeared to be buggy: there is no top-level `==` operator (or top-level operators at all) in JSONPath. This PR fixes the implementation of `type: change` to use the `[?(@.x == y)]` filter syntax which does appear to work (as tested by the migration tests for the new migration). This also renames a migration file added in #5957 that used a non-standard filename.
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.
Fix #3770
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. ↩