-
Notifications
You must be signed in to change notification settings - Fork 6
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
DOC-723 | Query plan caching #641
base: main
Are you sure you want to change the base?
Conversation
Deploy Preview Available Via |
- `explainRegisters` (internal) | ||
- `inaccessibleCollections` (internal) | ||
- `shardIds` (internal) |
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.
Internal, correct?
site/content/3.12/aql/execution-and-performance/caching-query-plans.md
Outdated
Show resolved
Hide resolved
site/content/3.12/develop/http-api/queries/aql-query-plan-cache.md
Outdated
Show resolved
Hide resolved
site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md
Outdated
Show resolved
Hide resolved
- An existing collection gets dropped or renamed, or the properties of an | ||
existing collection are modified |
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.
But only if the affected collection is in the list of data sources for the cached query plan? At least that's what I saw. On the other hand, dropping a named graph with no collections in common, the cache did get cleared.
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 a named graph is changed or dropped, the complete cache for that database is eradicated. If a data source is changed, only those entries which are affected are deleted.
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.
Note to self: Check again whether the entire cache is now cleared on any of these events, including e.g. changing the schema, computed values, or cacheEnabled of a collection in single server.
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.
In single server, the cache isn't necessarily cleared entirely but it depends on the operation. I suggest we add a vague remark to the docs that operations may only remove affected entries in single server.
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.
Generally LGTM, I have added a few suggestions.
site/content/3.12/aql/execution-and-performance/caching-query-plans.md
Outdated
Show resolved
Hide resolved
- An existing collection gets dropped or renamed, or the properties of an | ||
existing collection are modified |
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 a named graph is changed or dropped, the complete cache for that database is eradicated. If a data source is changed, only those entries which are affected are deleted.
* Add query options to HTTP and JS API reference * Review, examples, adjust to changed behavior * Move (results) cache option to query sub options * Apply to 3.13
/generate-commit |
/generate-commit |
Partially apply changes to 3.11
/generate-commit |
Description
Upstream PRs