diff --git a/site/content/3.11/aql/execution-and-performance/caching-query-results.md b/site/content/3.11/aql/execution-and-performance/caching-query-results.md
index 2013dd094..8e76741ee 100644
--- a/site/content/3.11/aql/execution-and-performance/caching-query-results.md
+++ b/site/content/3.11/aql/execution-and-performance/caching-query-results.md
@@ -21,48 +21,48 @@ are not part of a cluster setup.
The cache can be operated in the following modes:
-- `off`: the cache is disabled. No query results will be stored
-- `on`: the cache will store the results of all AQL queries unless their `cache`
- attribute flag is set to `false`
-- `demand`: the cache will store the results of AQL queries that have their
- `cache` attribute set to `true`, but will ignore all others
+- `off`: The cache is disabled. No query results are stored.
+- `on`: The cache stores the results of all AQL queries unless the `cache`
+ query option is set to `false`.
+- `demand`: The cache stores the results of AQL queries that have the
+ `cache` query option set to `true` but ignores all others.
-The mode can be set at server startup and later changed at runtime.
+The mode can be set at server startup as well as at runtime, see
+[Global configuration](#global-configuration).
## Query eligibility
-The query results cache will consider two queries identical if they have exactly the
+The query results cache considers two queries identical if they have exactly the
same query string and the same bind variables. Any deviation in terms of whitespace,
-capitalization etc. will be considered a difference. The query string will be hashed
-and used as the cache lookup key. If a query uses bind parameters, these will also be hashed
-and used as part of the cache lookup key.
-
-That means even if the query strings of two queries are identical, the query results
-cache will treat them as different queries if they have different bind parameter
-values. Other components that will become part of a query's cache key are the
-`count`, `fullCount` and `optimizer` attributes.
-
-If the cache is turned on, the cache will check at the very start of execution
-whether it has a result ready for this particular query. If that is the case,
-the query result will be served directly from the cache, which is normally
-very efficient. If the query cannot be found in the cache, it will be executed
+capitalization etc. is considered a difference. The query string is hashed
+and used as the cache lookup key. If a query uses bind parameters, these are also
+hashed and used as part of the cache lookup key.
+
+Even if the query strings of two queries are identical, the query results cache
+treats them as different queries if they have different bind parameter
+values. Other components that become part of a query's cache key are the
+`count`, `fullCount`, and `optimizer` attributes.
+
+If the cache is enabled, it is checked whether it has a result ready for a
+particular query at the very start of processing the query request. If this is
+the case, the query result is served directly from the cache, which is normally
+very efficient. If the query cannot be found in the cache, it is executed
as usual.
-If the query is eligible for caching and the cache is turned on, the query
-result will be stored in the query results cache so it can be used for subsequent
+If the query is eligible for caching and the cache is enabled, the query
+result is stored in the query results cache so it can be used for subsequent
executions of the same query.
A query is eligible for caching only if all of the following conditions are met:
-- the server the query executes on is a single server (i.e. not part of a cluster)
-- the query string is at least 8 characters long
-- the query is a read-only query and does not modify data in any collection
-- no warnings were produced while executing the query
-- the query is deterministic and only uses deterministic functions whose results
- are marked as cacheable
-- the size of the query result does not exceed the cache's configured maximal
- size for individual cache results or cumulated results
-- the query is not executed using a streaming cursor
+- The server the query executes on is a single server (i.e. not part of a cluster).
+- The query is a read-only query and does not modify data in any collection.
+- No warnings were produced while executing the query.
+- The query is deterministic and only uses deterministic functions whose results
+ are marked as cacheable.
+- The size of the query result does not exceed the cache's configured maximal
+ size for individual cache results or cumulated results.
+- The query is not executed using a streaming cursor (`"stream": true` query option).
The usage of non-deterministic functions leads to a query not being cacheable.
This is intentional to avoid caching of function results which should rather
@@ -85,8 +85,8 @@ remove, truncate operations as well as AQL data-modification queries).
**Example**
If the result of the following query is present in the query results cache,
-then either modifying data in collection `users` or in collection `organizations`
-will remove the already computed result from the cache:
+then either modifying data in the `users` or `organizations` collection
+removes the already computed result from the cache:
```aql
FOR user IN users
@@ -95,42 +95,42 @@ FOR user IN users
RETURN { user: user, organization: organization }
```
-Modifying data in other collections than the named two will not lead to this
+Modifying data in other unrelated collections does not lead to this
query result being removed from the cache.
## Performance considerations
The query results cache is organized as a hash table, so looking up whether a query result
-is present in the cache is relatively fast. Still, the query string and the bind
-parameter used in the query will need to be hashed. This is a slight overhead that
-will not be present if the cache is turned off or a query is marked as not cacheable.
+is present in the cache is fast. Still, the query string and the bind
+parameter used in the query need to be hashed. This is a slight overhead that
+is not present if the cache is disabled or a query is marked as not cacheable.
Additionally, storing query results in the cache and fetching results from the
-cache requires locking via an R/W lock. While many thread can read in parallel from
+cache requires locking via a read/write lock. While many thread can read in parallel from
the cache, there can only be a single modifying thread at any given time. Modifications
of the query cache contents are required when a query result is stored in the cache
or during cache invalidation after data-modification operations. Cache invalidation
-will require time proportional to the number of cached items that need to be invalidated.
+requires time proportional to the number of cached items that need to be invalidated.
-There may be workloads in which enabling the query results cache will lead to a performance
+There may be workloads in which enabling the query results cache leads to a performance
degradation. It is not recommended to turn the query results cache on in workloads that only
-modify data, or that modify data more often than reading it. Turning on the cache
-will also provide no benefit if queries are very diverse and do not repeat often.
-In read-only or read-mostly workloads, the cache will be beneficial if the same
+modify data, or that modify data more often than reading it. Enabling the cache
+also provides no benefit if queries are very diverse and do not repeat often.
+In read-only or read-mostly workloads, the cache is beneficial if the same
queries are repeated lots of times.
-In general, the query results cache will provide the biggest improvements for queries with
+In general, the query results cache provides the biggest improvements for queries with
small result sets that take long to calculate. If query results are very big and
most of the query time is spent on copying the result from the cache to the client,
-then the cache will not provide much benefit.
+then the cache does not provide much benefit.
## Global configuration
-The query results cache can be configured at server start using the configuration parameter
-`--query.cache-mode`. This will set the cache mode according to the descriptions
-above.
+The query results cache can be configured at server start with the
+[`--query.cache-mode`](../../components/arangodb-server/options.md#--querycache-mode)
+startup option.
-After the server is started, the cache mode can be changed at runtime as follows:
+The cache mode can also be changed at runtime using the JavaScript API as follows:
```js
require("@arangodb/aql/cache").properties({ mode: "on" });
@@ -139,10 +139,10 @@ require("@arangodb/aql/cache").properties({ mode: "on" });
The maximum number of cached results in the cache for each database can be configured
at server start using the following configuration parameters:
-- `--query.cache-entries`: maximum number of results in query result cache per database
-- `--query.cache-entries-max-size`: maximum cumulated size of results in query result cache per database
-- `--query.cache-entry-max-size`: maximum size of an individual result entry in query result cache
-- `--query.cache-include-system-collections`: whether or not to include system collection queries in the query result cache
+- `--query.cache-entries`: The maximum number of results in the query results cache per database
+- `--query.cache-entries-max-size`: The maximum cumulated size of results in the query results cache per database
+- `--query.cache-entry-max-size`: The maximum size of an individual result entry in query results cache
+- `--query.cache-include-system-collections`: Whether to include system collection queries in the query results cache
These parameters can be used to put an upper bound on the number and size of query
results in each database's query cache and thus restrict the cache's memory consumption.
@@ -158,27 +158,32 @@ require("@arangodb/aql/cache").properties({
});
```
-The above will limit the number of cached results in the query results cache to 200
-results per database, and to 8 MB cumulated query result size per database. The maximum
-size of each query cache entry is restricted to 8MB. Queries that involve system
+The above settings limit the number of cached results in the query results cache to 200
+results per database, and to 8 MiB cumulated query result size per database. The maximum
+size of each query cache entry is restricted to 1 MiB. Queries that involve system
collections are excluded from caching.
+You can also change the configuration at runtime with the
+[HTTP API](../../develop/http-api/queries/aql-query-results-cache.md).
+
## Per-query configuration
When a query is sent to the server for execution and the cache is set to `on` or `demand`,
-the query executor will look into the query's `cache` attribute. If the query cache mode is
-`on`, then not setting this attribute or setting it to anything but `false` will make the
-query executor consult the query cache. If the query cache mode is `demand`, then setting
-the `cache` attribute to `true` will make the executor look for the query in the query cache.
-When the query cache mode is `off`, the executor will not look for the query in the cache.
+the query executor checks the query's `cache` option. If the query cache mode is
+`on`, then not setting this query option or setting it to anything but `false` makes the
+query executor consult the query results cache. If the query cache mode is `demand`, then setting
+the `cache` option to `true` makes the executor look for the query in the query results cache.
+When the query cache mode is `off`, the executor does not look for the query in the cache.
The `cache` attribute can be set as follows via the `db._createStatement()` function:
```js
var stmt = db._createStatement({
query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+ options: {
+ cache: true
+ }
+});
stmt.execute();
```
@@ -186,16 +191,14 @@ stmt.execute();
When using the `db._query()` function, the `cache` attribute can be set as follows:
```js
-db._query({
- query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+db._query("FOR doc IN users LIMIT 5 RETURN doc", {}, { cache: true });
```
-The `cache` attribute can be set via the HTTP REST API `POST /_api/cursor`, too.
+You can also set the `cache` query option in the
+[HTTP API](../../develop/http-api/queries/aql-queries.md#create-a-cursor).
-Each query result returned will contain a `cached` attribute. This will be set to `true`
-if the result was retrieved from the query cache, and `false` otherwise. Clients can use
+Each query result returned contain a `cached` attribute. It is set to `true`
+if the result was retrieved from the query results cache, and `false` otherwise. Clients can use
this attribute to check if a specific query was served from the cache or not.
## Query results cache inspection
@@ -207,7 +210,7 @@ The contents of the query results cache can be checked at runtime using the cach
require("@arangodb/aql/cache").toArray();
```
-This will return a list of all query results stored in the current database's query
+This returns a list of all query results stored in the current database's query
results cache.
The query results cache for the current database can be cleared at runtime using the
@@ -221,5 +224,5 @@ require("@arangodb/aql/cache").clear();
Query results that are returned from the query results cache may contain execution statistics
stemming from the initial, uncached query execution. This means for a cached query results,
-the *extra.stats* attribute may contain stale data, especially in terms of the *executionTime*
-and *profile* attribute values.
+the `extra.stats` attribute may contain stale data, especially in terms of the `executionTime`
+and `profile` attribute values.
diff --git a/site/content/3.11/aql/how-to-invoke-aql/with-arangosh.md b/site/content/3.11/aql/how-to-invoke-aql/with-arangosh.md
index 1b3153028..20c0a0b70 100644
--- a/site/content/3.11/aql/how-to-invoke-aql/with-arangosh.md
+++ b/site/content/3.11/aql/how-to-invoke-aql/with-arangosh.md
@@ -195,26 +195,6 @@ db._query(
).toArray(); // Each batch needs to be fetched within 5 seconds
```
-#### `cache`
-
-Whether the AQL query results cache shall be used. If set to `false`, then any
-query cache lookup is skipped for the query. If set to `true`, it leads to the
-query cache being checked for the query **if** the query cache mode is either
-set to `on` or `demand`.
-
-```js
----
-name: 02_workWithAQL_cache
-description: ''
----
-db._query(
- 'FOR i IN 1..20 RETURN i',
- {},
- { cache: true },
- {}
-); // result may get taken from cache
-```
-
#### `memoryLimit`
To set a memory limit for the query, pass `options` to the `_query()` method.
@@ -274,12 +254,30 @@ don't need to set it on a per-query level.
#### `cache`
-If you set `cache` to `true`, this puts the query result into the query result cache
-if the query result is eligible for caching and the query cache is running in demand
-mode. If set to `false`, the query result is not inserted into the query result
-cache. Note that query results are never inserted into the query result cache if
-the query result cache is disabled, and that they are automatically inserted into
-the query result cache if it is active in non-demand mode.
+Whether the [AQL query results cache](../execution-and-performance/caching-query-results.md)
+shall be used for adding as well as for retrieving results.
+
+If the query cache mode is set to `demand` and you set the `cache` query option
+to `true` for a query, then its query result is cached if it's eligible for
+caching. If the query cache mode is set to `on`, query results are automatically
+cached if they are eligible for caching unless you set the `cache` option to `false`.
+
+If you set the `cache` option to `false`, then any query cache lookup is skipped
+for the query. If you set it to `true`, the query cache is checked a cached result
+**if** the query cache mode is either set to `on` or `demand`.
+
+```js
+---
+name: 02_workWithAQL_cache
+description: ''
+---
+var resultCache = require("@arangodb/aql/cache");
+resultCache.properties({ mode: "demand" });
+~resultCache.clear();
+db._query("FOR i IN 1..5 RETURN i", {}, { cache: true }); // Adds result to cache
+db._query("FOR i IN 1..5 RETURN i", {}, { cache: true }); // Retrieves result from cache
+db._query("FOR i IN 1..5 RETURN i", {}, { cache: false }); // Bypasses the cache
+```
#### `fillBlockCache`
diff --git a/site/content/3.11/develop/http-api/queries/aql-queries.md b/site/content/3.11/develop/http-api/queries/aql-queries.md
index c070a02b7..72a1a4677 100644
--- a/site/content/3.11/develop/http-api/queries/aql-queries.md
+++ b/site/content/3.11/develop/http-api/queries/aql-queries.md
@@ -347,13 +347,6 @@ paths:
of cursors that are not fully fetched by clients. If not set, a server-defined
value will be used (default: 30 seconds).
type: integer
- cache:
- description: |
- flag to determine whether the AQL query results cache
- shall be used. If set to `false`, then any query cache lookup will be skipped
- for the query. If set to `true`, it will lead to the query cache being checked
- for the query if the query cache mode is either `on` or `demand`.
- type: boolean
memoryLimit:
description: |
the maximum number of memory (measured in bytes) that the query is allowed to
@@ -493,6 +486,20 @@ paths:
All other resources are freed immediately (locks, RocksDB snapshots). The query
will fail before it returns results in case of a conflict.
type: boolean
+ cache:
+ description: |
+ Whether the [AQL query results cache](../../../aql/execution-and-performance/caching-query-results.md)
+ shall be used for adding as well as for retrieving results.
+
+ If the query cache mode is set to `demand` and you set the `cache` query option
+ to `true` for a query, then its query result is cached if it's eligible for
+ caching. If the query cache mode is set to `on`, query results are automatically
+ cached if they are eligible for caching unless you set the `cache` option to `false`.
+
+ If you set the `cache` option to `false`, then any query cache lookup is skipped
+ for the query. If you set it to `true`, the query cache is checked for a cached result
+ **if** the query cache mode is either set to `on` or `demand`.
+ type: boolean
spillOverThresholdMemoryUsage:
description: |
This option allows queries to store intermediate and final results temporarily
@@ -554,7 +561,7 @@ paths:
description: |
If set to `true` or `1`, then the additional query profiling information is returned
in the `profile` sub-attribute of the `extra` return attribute, unless the query result
- is served from the query cache. If set to `2`, the query includes execution stats
+ is served from the query results cache. If set to `2`, the query includes execution stats
per query plan node in `stats.nodes` sub-attribute of the `extra` return attribute.
Additionally, the query plan is returned in the `extra.plan` sub-attribute.
type: integer
@@ -963,9 +970,9 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
'400':
description: |
@@ -1690,9 +1697,9 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
'400':
description: |
@@ -2308,9 +2315,9 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
'400':
description: |
diff --git a/site/content/3.11/develop/http-api/queries/aql-query-results-cache.md b/site/content/3.11/develop/http-api/queries/aql-query-results-cache.md
index 14873d57f..670705ddb 100644
--- a/site/content/3.11/develop/http-api/queries/aql-query-results-cache.md
+++ b/site/content/3.11/develop/http-api/queries/aql-query-results-cache.md
@@ -1,10 +1,18 @@
---
-title: HTTP interface for the query cache
+title: HTTP interface for the query results cache
menuTitle: AQL query results cache
weight: 10
description: >-
- The query cache HTTP API lets you control the cache for AQL query results
+ The query results cache HTTP API lets you control the cache for AQL query results
---
+See [The AQL query results cache](../../../aql/execution-and-performance/caching-query-results.md)
+for a description of the feature and the configuration options.
+
+{{< info >}}
+The AQL query results cache is only available for single servers, i.e. servers that
+are not part of a cluster setup.
+{{< /info >}}
+
## List the entries of the AQL query results cache
```openapi
@@ -14,20 +22,7 @@ paths:
operationId: listQueryCacheResults
description: |
Returns an array containing the AQL query results currently stored in the query results
- cache of the selected database. Each result is a JSON object with the following attributes:
-
- - `hash`: the query result's hash
- - `query`: the query string
- - `bindVars`: the query's bind parameters. this attribute is only shown if tracking for
- bind variables was enabled at server start
- - `size`: the size of the query result and bind parameters, in bytes
- - `results`: number of documents/rows in the query result
- - `started`: the date and time when the query was stored in the cache
- - `hits`: number of times the result was served from the cache (can be
- `0` for queries that were only stored in the cache but were never accessed
- again afterwards)
- - `runTime`: the query's run time
- - `dataSources`: an array of collections/Views the query was using
+ cache of the selected database.
parameters:
- name: database-name
in: path
@@ -40,14 +35,103 @@ paths:
responses:
'200':
description: |
- Is returned when the list of results can be retrieved successfully.
+ The list of cached query results.
+ content:
+ application/json:
+ schema:
+ description: |
+ The entries of the query results cache.
+ type: array
+ items:
+ description: |
+ The properties of a cache entry.
+ type: object
+ required:
+ - hash
+ - query
+ - size
+ - results
+ - hits
+ - runTime
+ - started
+ - dataSources
+ properties:
+ hash:
+ description: |
+ The hash value calculated from the the query string,
+ certain query options, and the bind variables.
+ type: string
+ query:
+ description: |
+ The query string.
+ type: string
+ bindVars:
+ description: |
+ The bind parameters. This attribute is omitted if the
+ `--query.tracking-with-bindvars` startup option is set
+ to `false`.
+ type: object
+ size:
+ description: |
+ The size of the query result and bind parameters (in bytes).
+ type: integer
+ results:
+ description: |
+ The number of documents/rows in the query result.
+ type: integer
+ started:
+ description: |
+ The date and time at which the query result has been added
+ to the cache (in ISO 8601 format).
+ type: string
+ format: date-time
+ hits:
+ description: |
+ How many times the result has been served from the cache so far.
+ type: integer
+ runTime:
+ description: |
+ The total duration of the query in seconds.
+ type: number
+ dataSources:
+ description: |
+ The collections and Views involved in the query.
+ type: array
+ items:
+ type: string
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpListQueryResultsCache
+description: |
+ Retrieve the entries stored in the AQL query results cache of the current database:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+db._create("coll");
+for (let i = 0; i < 3; i++) {
+ db._query("FOR doc IN @@coll FILTER doc.attr == @val RETURN doc", {
+ "@coll": "coll", val: "foo"
+ }, { cache: true });
+}
+db._query("RETURN 42", {}, { cache: true });
+
+var url = "/_api/query-cache/entries";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.length >= 2);
+logJsonResponse(response);
+
+db._drop("coll");
+```
+
## Clear the AQL query results cache
```openapi
@@ -69,15 +153,44 @@ paths:
responses:
'200':
description: |
- The server will respond with *HTTP 200* when the cache was cleared
- successfully.
+ The results cache has been cleared.
+ content:
+ application/json:
+ schema:
+ type: object
+ required:
+ - error
+ - code
+ properties:
+ error:
+ description: |
+ A flag indicating that no error occurred.
+ type: boolean
+ example: false
+ code:
+ description: |
+ The HTTP response status code.
+ type: integer
+ example: 200
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request.
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpClearQueryResultsCache
+description: |
+ Clear the AQL query results cache of the current database:
+---
+var url = "/_api/query-cache";
+var response = logCurlRequest('DELETE', url);
+assert(response.code === 200);
+logJsonResponse(response);
+```
+
## Get the AQL query results cache configuration
```openapi
@@ -86,23 +199,7 @@ paths:
get:
operationId: getQueryCacheProperties
description: |
- Returns the global AQL query results cache configuration. The configuration is a
- JSON object with the following properties:
-
- - `mode`: the mode the AQL query results cache operates in. The mode is one of the following
- values: `off`, `on`, or `demand`.
-
- - `maxResults`: the maximum number of query results that will be stored per database-specific
- cache.
-
- - `maxResultsSize`: the maximum cumulated size of query results that will be stored per
- database-specific cache.
-
- - `maxEntrySize`: the maximum individual result size of queries that will be stored per
- database-specific cache.
-
- - `includeSystem`: whether or not results of queries that involve system collections will be
- stored in the query results cache.
+ Returns the global AQL query results cache configuration.
parameters:
- name: database-name
in: path
@@ -117,14 +214,62 @@ paths:
responses:
'200':
description: |
- Is returned if the properties can be retrieved successfully.
+ The result cache configuration is returned successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpGetQueryResultsCacheProperties
+description: |
+ Retrieve the global configuration of the AQL query results cache:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+var url = "/_api/query-cache/properties";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+logJsonResponse(response);
+```
+
## Set the AQL query results cache configuration
```openapi
@@ -135,14 +280,7 @@ paths:
description: |
Adjusts the global properties for the AQL query results cache.
- After the properties have been changed, the current set of properties will
- be returned in the HTTP response.
-
- Note: changing the properties may invalidate all results in the cache.
-
- The properties need to be passed in the `properties` attribute in the body
- of the HTTP request. `properties` needs to be a JSON object with the following
- properties:
+ Changing the properties may invalidate all results currently in the cache.
parameters:
- name: database-name
in: path
@@ -158,35 +296,90 @@ paths:
content:
application/json:
schema:
+ description: |
+ The result cache configuration settings to change.
type: object
properties:
mode:
description: |
- the mode the AQL query cache should operate in. Possible values are `off`, `on`, or `demand`.
+ The mode the AQL query cache shall operate in.
type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
maxResults:
description: |
- the maximum number of query results that will be stored per database-specific cache.
+ The maximum number of query results that are stored per
+ database-specific cache.
type: integer
maxResultsSize:
description: |
- the maximum cumulated size of query results that will be stored per database-specific cache.
+ The maximum cumulated size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
maxEntrySize:
description: |
- the maximum individual size of query results that will be stored per database-specific cache.
+ The maximum individual size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
includeSystem:
description: |
- whether or not to store results of queries that involve system collections.
+ Whether to store results of queries that involve
+ system collections in the cache.
type: boolean
responses:
'200':
description: |
- Is returned if the properties were changed successfully.
+ The result cache configuration has been changed successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+
+```curl
+---
+name: HttpSetQueryResultsCacheProperties
+description: |
+ Change some properties of the global configuration of the AQL query results cache:
+---
+var url = "/_api/query-cache/properties";
+var body = { mode: "demand", maxResults: 32 };
+var response = logCurlRequest('PUT', url, body);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+assert(response.parsedBody.maxResults == 32);
+logJsonResponse(response);
+```
diff --git a/site/content/3.11/develop/javascript-api/_index.md b/site/content/3.11/develop/javascript-api/_index.md
index 2a93b7575..ac10a520f 100644
--- a/site/content/3.11/develop/javascript-api/_index.md
+++ b/site/content/3.11/develop/javascript-api/_index.md
@@ -156,7 +156,7 @@ You can use the following modules as an end-user:
offers methods to track and kill AQL queries.
- [**@arangodb/aql/cache**](../../aql/execution-and-performance/caching-query-results.md)
- allows to control the AQL query caching feature.
+ allows to control the AQL query result caching feature.
- [**@arangodb/aql/explainer**](../../aql/execution-and-performance/explaining-queries.md)
provides methods to debug, explain and profile AQL queries.
diff --git a/site/content/3.12/aql/execution-and-performance/caching-query-plans.md b/site/content/3.12/aql/execution-and-performance/caching-query-plans.md
index d46cb7a43..4b57d3825 100644
--- a/site/content/3.12/aql/execution-and-performance/caching-query-plans.md
+++ b/site/content/3.12/aql/execution-and-performance/caching-query-plans.md
@@ -216,7 +216,7 @@ planCache.clear();
curl -XDELETE http://localhost:8529/_api/query-plan-cache
```
-See the [HTTP API](../../develop/http-api/queries/aql-query-plan-cache.md#clear-the-aql-query-results-cache)
+See the [HTTP API](../../develop/http-api/queries/aql-query-plan-cache.md#clear-the-aql-query-plan-cache)
for details.
{{< /tab >}}
diff --git a/site/content/3.12/aql/execution-and-performance/caching-query-results.md b/site/content/3.12/aql/execution-and-performance/caching-query-results.md
index 2013dd094..8e76741ee 100644
--- a/site/content/3.12/aql/execution-and-performance/caching-query-results.md
+++ b/site/content/3.12/aql/execution-and-performance/caching-query-results.md
@@ -21,48 +21,48 @@ are not part of a cluster setup.
The cache can be operated in the following modes:
-- `off`: the cache is disabled. No query results will be stored
-- `on`: the cache will store the results of all AQL queries unless their `cache`
- attribute flag is set to `false`
-- `demand`: the cache will store the results of AQL queries that have their
- `cache` attribute set to `true`, but will ignore all others
+- `off`: The cache is disabled. No query results are stored.
+- `on`: The cache stores the results of all AQL queries unless the `cache`
+ query option is set to `false`.
+- `demand`: The cache stores the results of AQL queries that have the
+ `cache` query option set to `true` but ignores all others.
-The mode can be set at server startup and later changed at runtime.
+The mode can be set at server startup as well as at runtime, see
+[Global configuration](#global-configuration).
## Query eligibility
-The query results cache will consider two queries identical if they have exactly the
+The query results cache considers two queries identical if they have exactly the
same query string and the same bind variables. Any deviation in terms of whitespace,
-capitalization etc. will be considered a difference. The query string will be hashed
-and used as the cache lookup key. If a query uses bind parameters, these will also be hashed
-and used as part of the cache lookup key.
-
-That means even if the query strings of two queries are identical, the query results
-cache will treat them as different queries if they have different bind parameter
-values. Other components that will become part of a query's cache key are the
-`count`, `fullCount` and `optimizer` attributes.
-
-If the cache is turned on, the cache will check at the very start of execution
-whether it has a result ready for this particular query. If that is the case,
-the query result will be served directly from the cache, which is normally
-very efficient. If the query cannot be found in the cache, it will be executed
+capitalization etc. is considered a difference. The query string is hashed
+and used as the cache lookup key. If a query uses bind parameters, these are also
+hashed and used as part of the cache lookup key.
+
+Even if the query strings of two queries are identical, the query results cache
+treats them as different queries if they have different bind parameter
+values. Other components that become part of a query's cache key are the
+`count`, `fullCount`, and `optimizer` attributes.
+
+If the cache is enabled, it is checked whether it has a result ready for a
+particular query at the very start of processing the query request. If this is
+the case, the query result is served directly from the cache, which is normally
+very efficient. If the query cannot be found in the cache, it is executed
as usual.
-If the query is eligible for caching and the cache is turned on, the query
-result will be stored in the query results cache so it can be used for subsequent
+If the query is eligible for caching and the cache is enabled, the query
+result is stored in the query results cache so it can be used for subsequent
executions of the same query.
A query is eligible for caching only if all of the following conditions are met:
-- the server the query executes on is a single server (i.e. not part of a cluster)
-- the query string is at least 8 characters long
-- the query is a read-only query and does not modify data in any collection
-- no warnings were produced while executing the query
-- the query is deterministic and only uses deterministic functions whose results
- are marked as cacheable
-- the size of the query result does not exceed the cache's configured maximal
- size for individual cache results or cumulated results
-- the query is not executed using a streaming cursor
+- The server the query executes on is a single server (i.e. not part of a cluster).
+- The query is a read-only query and does not modify data in any collection.
+- No warnings were produced while executing the query.
+- The query is deterministic and only uses deterministic functions whose results
+ are marked as cacheable.
+- The size of the query result does not exceed the cache's configured maximal
+ size for individual cache results or cumulated results.
+- The query is not executed using a streaming cursor (`"stream": true` query option).
The usage of non-deterministic functions leads to a query not being cacheable.
This is intentional to avoid caching of function results which should rather
@@ -85,8 +85,8 @@ remove, truncate operations as well as AQL data-modification queries).
**Example**
If the result of the following query is present in the query results cache,
-then either modifying data in collection `users` or in collection `organizations`
-will remove the already computed result from the cache:
+then either modifying data in the `users` or `organizations` collection
+removes the already computed result from the cache:
```aql
FOR user IN users
@@ -95,42 +95,42 @@ FOR user IN users
RETURN { user: user, organization: organization }
```
-Modifying data in other collections than the named two will not lead to this
+Modifying data in other unrelated collections does not lead to this
query result being removed from the cache.
## Performance considerations
The query results cache is organized as a hash table, so looking up whether a query result
-is present in the cache is relatively fast. Still, the query string and the bind
-parameter used in the query will need to be hashed. This is a slight overhead that
-will not be present if the cache is turned off or a query is marked as not cacheable.
+is present in the cache is fast. Still, the query string and the bind
+parameter used in the query need to be hashed. This is a slight overhead that
+is not present if the cache is disabled or a query is marked as not cacheable.
Additionally, storing query results in the cache and fetching results from the
-cache requires locking via an R/W lock. While many thread can read in parallel from
+cache requires locking via a read/write lock. While many thread can read in parallel from
the cache, there can only be a single modifying thread at any given time. Modifications
of the query cache contents are required when a query result is stored in the cache
or during cache invalidation after data-modification operations. Cache invalidation
-will require time proportional to the number of cached items that need to be invalidated.
+requires time proportional to the number of cached items that need to be invalidated.
-There may be workloads in which enabling the query results cache will lead to a performance
+There may be workloads in which enabling the query results cache leads to a performance
degradation. It is not recommended to turn the query results cache on in workloads that only
-modify data, or that modify data more often than reading it. Turning on the cache
-will also provide no benefit if queries are very diverse and do not repeat often.
-In read-only or read-mostly workloads, the cache will be beneficial if the same
+modify data, or that modify data more often than reading it. Enabling the cache
+also provides no benefit if queries are very diverse and do not repeat often.
+In read-only or read-mostly workloads, the cache is beneficial if the same
queries are repeated lots of times.
-In general, the query results cache will provide the biggest improvements for queries with
+In general, the query results cache provides the biggest improvements for queries with
small result sets that take long to calculate. If query results are very big and
most of the query time is spent on copying the result from the cache to the client,
-then the cache will not provide much benefit.
+then the cache does not provide much benefit.
## Global configuration
-The query results cache can be configured at server start using the configuration parameter
-`--query.cache-mode`. This will set the cache mode according to the descriptions
-above.
+The query results cache can be configured at server start with the
+[`--query.cache-mode`](../../components/arangodb-server/options.md#--querycache-mode)
+startup option.
-After the server is started, the cache mode can be changed at runtime as follows:
+The cache mode can also be changed at runtime using the JavaScript API as follows:
```js
require("@arangodb/aql/cache").properties({ mode: "on" });
@@ -139,10 +139,10 @@ require("@arangodb/aql/cache").properties({ mode: "on" });
The maximum number of cached results in the cache for each database can be configured
at server start using the following configuration parameters:
-- `--query.cache-entries`: maximum number of results in query result cache per database
-- `--query.cache-entries-max-size`: maximum cumulated size of results in query result cache per database
-- `--query.cache-entry-max-size`: maximum size of an individual result entry in query result cache
-- `--query.cache-include-system-collections`: whether or not to include system collection queries in the query result cache
+- `--query.cache-entries`: The maximum number of results in the query results cache per database
+- `--query.cache-entries-max-size`: The maximum cumulated size of results in the query results cache per database
+- `--query.cache-entry-max-size`: The maximum size of an individual result entry in query results cache
+- `--query.cache-include-system-collections`: Whether to include system collection queries in the query results cache
These parameters can be used to put an upper bound on the number and size of query
results in each database's query cache and thus restrict the cache's memory consumption.
@@ -158,27 +158,32 @@ require("@arangodb/aql/cache").properties({
});
```
-The above will limit the number of cached results in the query results cache to 200
-results per database, and to 8 MB cumulated query result size per database. The maximum
-size of each query cache entry is restricted to 8MB. Queries that involve system
+The above settings limit the number of cached results in the query results cache to 200
+results per database, and to 8 MiB cumulated query result size per database. The maximum
+size of each query cache entry is restricted to 1 MiB. Queries that involve system
collections are excluded from caching.
+You can also change the configuration at runtime with the
+[HTTP API](../../develop/http-api/queries/aql-query-results-cache.md).
+
## Per-query configuration
When a query is sent to the server for execution and the cache is set to `on` or `demand`,
-the query executor will look into the query's `cache` attribute. If the query cache mode is
-`on`, then not setting this attribute or setting it to anything but `false` will make the
-query executor consult the query cache. If the query cache mode is `demand`, then setting
-the `cache` attribute to `true` will make the executor look for the query in the query cache.
-When the query cache mode is `off`, the executor will not look for the query in the cache.
+the query executor checks the query's `cache` option. If the query cache mode is
+`on`, then not setting this query option or setting it to anything but `false` makes the
+query executor consult the query results cache. If the query cache mode is `demand`, then setting
+the `cache` option to `true` makes the executor look for the query in the query results cache.
+When the query cache mode is `off`, the executor does not look for the query in the cache.
The `cache` attribute can be set as follows via the `db._createStatement()` function:
```js
var stmt = db._createStatement({
query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+ options: {
+ cache: true
+ }
+});
stmt.execute();
```
@@ -186,16 +191,14 @@ stmt.execute();
When using the `db._query()` function, the `cache` attribute can be set as follows:
```js
-db._query({
- query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+db._query("FOR doc IN users LIMIT 5 RETURN doc", {}, { cache: true });
```
-The `cache` attribute can be set via the HTTP REST API `POST /_api/cursor`, too.
+You can also set the `cache` query option in the
+[HTTP API](../../develop/http-api/queries/aql-queries.md#create-a-cursor).
-Each query result returned will contain a `cached` attribute. This will be set to `true`
-if the result was retrieved from the query cache, and `false` otherwise. Clients can use
+Each query result returned contain a `cached` attribute. It is set to `true`
+if the result was retrieved from the query results cache, and `false` otherwise. Clients can use
this attribute to check if a specific query was served from the cache or not.
## Query results cache inspection
@@ -207,7 +210,7 @@ The contents of the query results cache can be checked at runtime using the cach
require("@arangodb/aql/cache").toArray();
```
-This will return a list of all query results stored in the current database's query
+This returns a list of all query results stored in the current database's query
results cache.
The query results cache for the current database can be cleared at runtime using the
@@ -221,5 +224,5 @@ require("@arangodb/aql/cache").clear();
Query results that are returned from the query results cache may contain execution statistics
stemming from the initial, uncached query execution. This means for a cached query results,
-the *extra.stats* attribute may contain stale data, especially in terms of the *executionTime*
-and *profile* attribute values.
+the `extra.stats` attribute may contain stale data, especially in terms of the `executionTime`
+and `profile` attribute values.
diff --git a/site/content/3.12/develop/http-api/queries/aql-queries.md b/site/content/3.12/develop/http-api/queries/aql-queries.md
index d51072278..d5479d733 100644
--- a/site/content/3.12/develop/http-api/queries/aql-queries.md
+++ b/site/content/3.12/develop/http-api/queries/aql-queries.md
@@ -577,7 +577,7 @@ paths:
description: |
If set to `true` or `1`, then the additional query profiling information is returned
in the `profile` sub-attribute of the `extra` return attribute, unless the query result
- is served from the query cache. If set to `2`, the query includes execution stats
+ is served from the query results cache. If set to `2`, the query includes execution stats
per query plan node in `stats.nodes` sub-attribute of the `extra` return attribute.
Additionally, the query plan is returned in the `extra.plan` sub-attribute.
type: integer
@@ -1000,10 +1000,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
is returned if the JSON representation is malformed, the query specification is
@@ -1744,10 +1749,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
If the cursor identifier is omitted, the server will respond with *HTTP 404*.
@@ -2381,10 +2391,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
If the cursor and the batch identifier are omitted, the server responds with
@@ -3055,6 +3070,21 @@ paths:
type: array
items:
type: string
+ usePlanCache:
+ description: |
+ Set this option to `true` to utilize a cached query plan or add the execution plan
+ of this query to the cache if it's not in the cache yet. Otherwise, the plan cache
+ is bypassed.
+
+ Query plan caching can reduce the total time for processing queries by avoiding
+ to parse, plan, and optimize queries over and over again that effectively have
+ the same execution plan with at most some changes to bind parameter values.
+
+ An error is raised if a query doesn't meet the requirements for plan caching.
+ See [Cache eligibility](../../../aql/execution-and-performance/caching-query-plans.md#cache-eligibility)
+ for details.
+ type: boolean
+ default: false
responses:
'200':
description: |
diff --git a/site/content/3.12/develop/http-api/queries/aql-query-plan-cache.md b/site/content/3.12/develop/http-api/queries/aql-query-plan-cache.md
index 2ee947f77..57706ea4c 100644
--- a/site/content/3.12/develop/http-api/queries/aql-query-plan-cache.md
+++ b/site/content/3.12/develop/http-api/queries/aql-query-plan-cache.md
@@ -51,7 +51,7 @@ paths:
- fullCount
- dataSources
- created
- - numUsed
+ - hits
- memoryUsage
properties:
hash:
@@ -75,7 +75,8 @@ paths:
fullCount:
description: |
The value of the `fullCount` query option in the
- original query.
+ original query. This option generally leads to different
+ execution plans.
type: boolean
dataSources:
description: |
@@ -89,7 +90,7 @@ paths:
to the cache (in ISO 8601 format).
type: string
format: date-time
- numUsed:
+ hits:
description: |
How many times the cached plan has been utilized so far.
type: integer
@@ -102,7 +103,30 @@ paths:
- Queries
```
-## Clear the AQL query results cache
+```curl
+---
+name: HttpListQueryPlanCache
+description: |
+ Retrieve the entries stored in the AQL query plan cache of the current database:
+---
+db._create("coll");
+for (let i = 0; i < 3; i++) {
+ db._query("FOR doc IN @@coll FILTER doc.attr == @val RETURN doc", {
+ "@coll": "coll", val: "foo"
+ }, { usePlanCache: true });
+}
+db._query("RETURN 42", {}, { usePlanCache: true });
+
+var url = "/_api/query-plan-cache";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.length >= 2);
+logJsonResponse(response);
+
+db._drop("coll");
+```
+
+## Clear the AQL query plan cache
```openapi
paths:
@@ -147,4 +171,16 @@ paths:
example: 200
tags:
- Queries
-```
\ No newline at end of file
+```
+
+```curl
+---
+name: HttpClearQueryPlanCache
+description: |
+ Clear the AQL query plan cache of the current database:
+---
+var url = "/_api/query-plan-cache";
+var response = logCurlRequest('DELETE', url);
+assert(response.code === 200);
+logJsonResponse(response);
+```
diff --git a/site/content/3.12/develop/http-api/queries/aql-query-results-cache.md b/site/content/3.12/develop/http-api/queries/aql-query-results-cache.md
index 9c0832999..77325280a 100644
--- a/site/content/3.12/develop/http-api/queries/aql-query-results-cache.md
+++ b/site/content/3.12/develop/http-api/queries/aql-query-results-cache.md
@@ -5,6 +5,14 @@ weight: 10
description: >-
The query results cache HTTP API lets you control the cache for AQL query results
---
+See [The AQL query results cache](../../../aql/execution-and-performance/caching-query-results.md)
+for a description of the feature and the configuration options.
+
+{{< info >}}
+The AQL query results cache is only available for single servers, i.e. servers that
+are not part of a cluster setup.
+{{< /info >}}
+
## List the entries of the AQL query results cache
```openapi
@@ -14,20 +22,7 @@ paths:
operationId: listQueryCacheResults
description: |
Returns an array containing the AQL query results currently stored in the query results
- cache of the selected database. Each result is a JSON object with the following attributes:
-
- - `hash`: the query result's hash
- - `query`: the query string
- - `bindVars`: the query's bind parameters. this attribute is only shown if tracking for
- bind variables was enabled at server start
- - `size`: the size of the query result and bind parameters, in bytes
- - `results`: number of documents/rows in the query result
- - `started`: the date and time when the query was stored in the cache
- - `hits`: number of times the result was served from the cache (can be
- `0` for queries that were only stored in the cache but were never accessed
- again afterwards)
- - `runTime`: the query's run time
- - `dataSources`: an array of collections/Views the query was using
+ cache of the selected database.
parameters:
- name: database-name
in: path
@@ -40,14 +35,103 @@ paths:
responses:
'200':
description: |
- Is returned when the list of results can be retrieved successfully.
+ The list of cached query results.
+ content:
+ application/json:
+ schema:
+ description: |
+ The entries of the query results cache.
+ type: array
+ items:
+ description: |
+ The properties of a cache entry.
+ type: object
+ required:
+ - hash
+ - query
+ - size
+ - results
+ - hits
+ - runTime
+ - started
+ - dataSources
+ properties:
+ hash:
+ description: |
+ The hash value calculated from the the query string,
+ certain query options, and the bind variables.
+ type: string
+ query:
+ description: |
+ The query string.
+ type: string
+ bindVars:
+ description: |
+ The bind parameters. This attribute is omitted if the
+ `--query.tracking-with-bindvars` startup option is set
+ to `false`.
+ type: object
+ size:
+ description: |
+ The size of the query result and bind parameters (in bytes).
+ type: integer
+ results:
+ description: |
+ The number of documents/rows in the query result.
+ type: integer
+ started:
+ description: |
+ The date and time at which the query result has been added
+ to the cache (in ISO 8601 format).
+ type: string
+ format: date-time
+ hits:
+ description: |
+ How many times the result has been served from the cache so far.
+ type: integer
+ runTime:
+ description: |
+ The total duration of the query in seconds.
+ type: number
+ dataSources:
+ description: |
+ The collections and Views involved in the query.
+ type: array
+ items:
+ type: string
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpListQueryResultsCache
+description: |
+ Retrieve the entries stored in the AQL query results cache of the current database:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+db._create("coll");
+for (let i = 0; i < 3; i++) {
+ db._query("FOR doc IN @@coll FILTER doc.attr == @val RETURN doc", {
+ "@coll": "coll", val: "foo"
+ }, { cache: true, fullCount: true });
+}
+db._query("RETURN 42", {}, { cache: true });
+
+var url = "/_api/query-cache/entries";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.length >= 2);
+logJsonResponse(response);
+
+db._drop("coll");
+```
+
## Clear the AQL query results cache
```openapi
@@ -69,15 +153,44 @@ paths:
responses:
'200':
description: |
- The server will respond with *HTTP 200* when the cache was cleared
- successfully.
+ The results cache has been cleared.
+ content:
+ application/json:
+ schema:
+ type: object
+ required:
+ - error
+ - code
+ properties:
+ error:
+ description: |
+ A flag indicating that no error occurred.
+ type: boolean
+ example: false
+ code:
+ description: |
+ The HTTP response status code.
+ type: integer
+ example: 200
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request.
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpClearQueryResultsCache
+description: |
+ Clear the AQL query results cache of the current database:
+---
+var url = "/_api/query-cache";
+var response = logCurlRequest('DELETE', url);
+assert(response.code === 200);
+logJsonResponse(response);
+```
+
## Get the AQL query results cache configuration
```openapi
@@ -86,23 +199,7 @@ paths:
get:
operationId: getQueryCacheProperties
description: |
- Returns the global AQL query results cache configuration. The configuration is a
- JSON object with the following properties:
-
- - `mode`: the mode the AQL query results cache operates in. The mode is one of the following
- values: `off`, `on`, or `demand`.
-
- - `maxResults`: the maximum number of query results that will be stored per database-specific
- cache.
-
- - `maxResultsSize`: the maximum cumulated size of query results that will be stored per
- database-specific cache.
-
- - `maxEntrySize`: the maximum individual result size of queries that will be stored per
- database-specific cache.
-
- - `includeSystem`: whether or not results of queries that involve system collections will be
- stored in the query results cache.
+ Returns the global AQL query results cache configuration.
parameters:
- name: database-name
in: path
@@ -117,14 +214,62 @@ paths:
responses:
'200':
description: |
- Is returned if the properties can be retrieved successfully.
+ The result cache configuration is returned successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpGetQueryResultsCacheProperties
+description: |
+ Retrieve the global configuration of the AQL query results cache:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+var url = "/_api/query-cache/properties";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+logJsonResponse(response);
+```
+
## Set the AQL query results cache configuration
```openapi
@@ -135,14 +280,7 @@ paths:
description: |
Adjusts the global properties for the AQL query results cache.
- After the properties have been changed, the current set of properties will
- be returned in the HTTP response.
-
- Note: changing the properties may invalidate all results in the cache.
-
- The properties need to be passed in the `properties` attribute in the body
- of the HTTP request. `properties` needs to be a JSON object with the following
- properties:
+ Changing the properties may invalidate all results currently in the cache.
parameters:
- name: database-name
in: path
@@ -158,35 +296,90 @@ paths:
content:
application/json:
schema:
+ description: |
+ The result cache configuration settings to change.
type: object
properties:
mode:
description: |
- the mode the AQL query cache should operate in. Possible values are `off`, `on`, or `demand`.
+ The mode the AQL query cache shall operate in.
type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
maxResults:
description: |
- the maximum number of query results that will be stored per database-specific cache.
+ The maximum number of query results that are stored per
+ database-specific cache.
type: integer
maxResultsSize:
description: |
- the maximum cumulated size of query results that will be stored per database-specific cache.
+ The maximum cumulated size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
maxEntrySize:
description: |
- the maximum individual size of query results that will be stored per database-specific cache.
+ The maximum individual size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
includeSystem:
description: |
- whether or not to store results of queries that involve system collections.
+ Whether to store results of queries that involve
+ system collections in the cache.
type: boolean
responses:
'200':
description: |
- Is returned if the properties were changed successfully.
+ The result cache configuration has been changed successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+
+```curl
+---
+name: HttpSetQueryResultsCacheProperties
+description: |
+ Change some properties of the global configuration of the AQL query results cache:
+---
+var url = "/_api/query-cache/properties";
+var body = { mode: "demand", maxResults: 32 };
+var response = logCurlRequest('PUT', url, body);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+assert(response.parsedBody.maxResults == 32);
+logJsonResponse(response);
+```
diff --git a/site/content/3.12/release-notes/version-3.12/api-changes-in-3-12.md b/site/content/3.12/release-notes/version-3.12/api-changes-in-3-12.md
index 24c0cfc24..83375279d 100644
--- a/site/content/3.12/release-notes/version-3.12/api-changes-in-3-12.md
+++ b/site/content/3.12/release-notes/version-3.12/api-changes-in-3-12.md
@@ -353,6 +353,29 @@ Two new statistics are included in the response when you execute an AQL query:
}
```
+#### Query plan cache attributes
+
+Introduced in: v3.12.4
+
+The following endpoints related to AQL queries support a new `usePlanCache`
+query option in the `options` object:
+
+- `POST /_api/cursor`
+- `POST /_api/explain`
+
+An error is raised if `usePlanCache` is set to `true` but the query is not
+eligible for plan caching (a new error code
+`ERROR_QUERY_NOT_ELIGIBLE_FOR_PLAN_CACHING` with the number `1584`). See
+[The execution plan cache for AQL queries](../../aql/execution-and-performance/caching-query-plans.md)
+for details.
+
+If a cached query plan is utilized, the above endpoints include a new
+`planCacheKey` attribute at the top-level of the response with the key of the
+cached plan (string).
+
+See [HTTP interfaces for AQL queries](../../develop/http-api/queries/aql-queries.md#cursors)
+for details.
+
#### Index API
##### `optimizeTopK` for inverted indexes
diff --git a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md
index 0aa5ee0c4..c04fefa8c 100644
--- a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md
+++ b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md
@@ -1016,7 +1016,7 @@ require("@arangodb/aql/plan-cache").toArray();
"coll"
],
"created" : "2024-11-20T17:21:34Z",
- "numUsed" : 0,
+ "hits" : 0,
"memoryUsage" : 3070
}
]
diff --git a/site/content/3.13/aql/execution-and-performance/caching-query-plans.md b/site/content/3.13/aql/execution-and-performance/caching-query-plans.md
index d46cb7a43..4b57d3825 100644
--- a/site/content/3.13/aql/execution-and-performance/caching-query-plans.md
+++ b/site/content/3.13/aql/execution-and-performance/caching-query-plans.md
@@ -216,7 +216,7 @@ planCache.clear();
curl -XDELETE http://localhost:8529/_api/query-plan-cache
```
-See the [HTTP API](../../develop/http-api/queries/aql-query-plan-cache.md#clear-the-aql-query-results-cache)
+See the [HTTP API](../../develop/http-api/queries/aql-query-plan-cache.md#clear-the-aql-query-plan-cache)
for details.
{{< /tab >}}
diff --git a/site/content/3.13/aql/execution-and-performance/caching-query-results.md b/site/content/3.13/aql/execution-and-performance/caching-query-results.md
index 2013dd094..8e76741ee 100644
--- a/site/content/3.13/aql/execution-and-performance/caching-query-results.md
+++ b/site/content/3.13/aql/execution-and-performance/caching-query-results.md
@@ -21,48 +21,48 @@ are not part of a cluster setup.
The cache can be operated in the following modes:
-- `off`: the cache is disabled. No query results will be stored
-- `on`: the cache will store the results of all AQL queries unless their `cache`
- attribute flag is set to `false`
-- `demand`: the cache will store the results of AQL queries that have their
- `cache` attribute set to `true`, but will ignore all others
+- `off`: The cache is disabled. No query results are stored.
+- `on`: The cache stores the results of all AQL queries unless the `cache`
+ query option is set to `false`.
+- `demand`: The cache stores the results of AQL queries that have the
+ `cache` query option set to `true` but ignores all others.
-The mode can be set at server startup and later changed at runtime.
+The mode can be set at server startup as well as at runtime, see
+[Global configuration](#global-configuration).
## Query eligibility
-The query results cache will consider two queries identical if they have exactly the
+The query results cache considers two queries identical if they have exactly the
same query string and the same bind variables. Any deviation in terms of whitespace,
-capitalization etc. will be considered a difference. The query string will be hashed
-and used as the cache lookup key. If a query uses bind parameters, these will also be hashed
-and used as part of the cache lookup key.
-
-That means even if the query strings of two queries are identical, the query results
-cache will treat them as different queries if they have different bind parameter
-values. Other components that will become part of a query's cache key are the
-`count`, `fullCount` and `optimizer` attributes.
-
-If the cache is turned on, the cache will check at the very start of execution
-whether it has a result ready for this particular query. If that is the case,
-the query result will be served directly from the cache, which is normally
-very efficient. If the query cannot be found in the cache, it will be executed
+capitalization etc. is considered a difference. The query string is hashed
+and used as the cache lookup key. If a query uses bind parameters, these are also
+hashed and used as part of the cache lookup key.
+
+Even if the query strings of two queries are identical, the query results cache
+treats them as different queries if they have different bind parameter
+values. Other components that become part of a query's cache key are the
+`count`, `fullCount`, and `optimizer` attributes.
+
+If the cache is enabled, it is checked whether it has a result ready for a
+particular query at the very start of processing the query request. If this is
+the case, the query result is served directly from the cache, which is normally
+very efficient. If the query cannot be found in the cache, it is executed
as usual.
-If the query is eligible for caching and the cache is turned on, the query
-result will be stored in the query results cache so it can be used for subsequent
+If the query is eligible for caching and the cache is enabled, the query
+result is stored in the query results cache so it can be used for subsequent
executions of the same query.
A query is eligible for caching only if all of the following conditions are met:
-- the server the query executes on is a single server (i.e. not part of a cluster)
-- the query string is at least 8 characters long
-- the query is a read-only query and does not modify data in any collection
-- no warnings were produced while executing the query
-- the query is deterministic and only uses deterministic functions whose results
- are marked as cacheable
-- the size of the query result does not exceed the cache's configured maximal
- size for individual cache results or cumulated results
-- the query is not executed using a streaming cursor
+- The server the query executes on is a single server (i.e. not part of a cluster).
+- The query is a read-only query and does not modify data in any collection.
+- No warnings were produced while executing the query.
+- The query is deterministic and only uses deterministic functions whose results
+ are marked as cacheable.
+- The size of the query result does not exceed the cache's configured maximal
+ size for individual cache results or cumulated results.
+- The query is not executed using a streaming cursor (`"stream": true` query option).
The usage of non-deterministic functions leads to a query not being cacheable.
This is intentional to avoid caching of function results which should rather
@@ -85,8 +85,8 @@ remove, truncate operations as well as AQL data-modification queries).
**Example**
If the result of the following query is present in the query results cache,
-then either modifying data in collection `users` or in collection `organizations`
-will remove the already computed result from the cache:
+then either modifying data in the `users` or `organizations` collection
+removes the already computed result from the cache:
```aql
FOR user IN users
@@ -95,42 +95,42 @@ FOR user IN users
RETURN { user: user, organization: organization }
```
-Modifying data in other collections than the named two will not lead to this
+Modifying data in other unrelated collections does not lead to this
query result being removed from the cache.
## Performance considerations
The query results cache is organized as a hash table, so looking up whether a query result
-is present in the cache is relatively fast. Still, the query string and the bind
-parameter used in the query will need to be hashed. This is a slight overhead that
-will not be present if the cache is turned off or a query is marked as not cacheable.
+is present in the cache is fast. Still, the query string and the bind
+parameter used in the query need to be hashed. This is a slight overhead that
+is not present if the cache is disabled or a query is marked as not cacheable.
Additionally, storing query results in the cache and fetching results from the
-cache requires locking via an R/W lock. While many thread can read in parallel from
+cache requires locking via a read/write lock. While many thread can read in parallel from
the cache, there can only be a single modifying thread at any given time. Modifications
of the query cache contents are required when a query result is stored in the cache
or during cache invalidation after data-modification operations. Cache invalidation
-will require time proportional to the number of cached items that need to be invalidated.
+requires time proportional to the number of cached items that need to be invalidated.
-There may be workloads in which enabling the query results cache will lead to a performance
+There may be workloads in which enabling the query results cache leads to a performance
degradation. It is not recommended to turn the query results cache on in workloads that only
-modify data, or that modify data more often than reading it. Turning on the cache
-will also provide no benefit if queries are very diverse and do not repeat often.
-In read-only or read-mostly workloads, the cache will be beneficial if the same
+modify data, or that modify data more often than reading it. Enabling the cache
+also provides no benefit if queries are very diverse and do not repeat often.
+In read-only or read-mostly workloads, the cache is beneficial if the same
queries are repeated lots of times.
-In general, the query results cache will provide the biggest improvements for queries with
+In general, the query results cache provides the biggest improvements for queries with
small result sets that take long to calculate. If query results are very big and
most of the query time is spent on copying the result from the cache to the client,
-then the cache will not provide much benefit.
+then the cache does not provide much benefit.
## Global configuration
-The query results cache can be configured at server start using the configuration parameter
-`--query.cache-mode`. This will set the cache mode according to the descriptions
-above.
+The query results cache can be configured at server start with the
+[`--query.cache-mode`](../../components/arangodb-server/options.md#--querycache-mode)
+startup option.
-After the server is started, the cache mode can be changed at runtime as follows:
+The cache mode can also be changed at runtime using the JavaScript API as follows:
```js
require("@arangodb/aql/cache").properties({ mode: "on" });
@@ -139,10 +139,10 @@ require("@arangodb/aql/cache").properties({ mode: "on" });
The maximum number of cached results in the cache for each database can be configured
at server start using the following configuration parameters:
-- `--query.cache-entries`: maximum number of results in query result cache per database
-- `--query.cache-entries-max-size`: maximum cumulated size of results in query result cache per database
-- `--query.cache-entry-max-size`: maximum size of an individual result entry in query result cache
-- `--query.cache-include-system-collections`: whether or not to include system collection queries in the query result cache
+- `--query.cache-entries`: The maximum number of results in the query results cache per database
+- `--query.cache-entries-max-size`: The maximum cumulated size of results in the query results cache per database
+- `--query.cache-entry-max-size`: The maximum size of an individual result entry in query results cache
+- `--query.cache-include-system-collections`: Whether to include system collection queries in the query results cache
These parameters can be used to put an upper bound on the number and size of query
results in each database's query cache and thus restrict the cache's memory consumption.
@@ -158,27 +158,32 @@ require("@arangodb/aql/cache").properties({
});
```
-The above will limit the number of cached results in the query results cache to 200
-results per database, and to 8 MB cumulated query result size per database. The maximum
-size of each query cache entry is restricted to 8MB. Queries that involve system
+The above settings limit the number of cached results in the query results cache to 200
+results per database, and to 8 MiB cumulated query result size per database. The maximum
+size of each query cache entry is restricted to 1 MiB. Queries that involve system
collections are excluded from caching.
+You can also change the configuration at runtime with the
+[HTTP API](../../develop/http-api/queries/aql-query-results-cache.md).
+
## Per-query configuration
When a query is sent to the server for execution and the cache is set to `on` or `demand`,
-the query executor will look into the query's `cache` attribute. If the query cache mode is
-`on`, then not setting this attribute or setting it to anything but `false` will make the
-query executor consult the query cache. If the query cache mode is `demand`, then setting
-the `cache` attribute to `true` will make the executor look for the query in the query cache.
-When the query cache mode is `off`, the executor will not look for the query in the cache.
+the query executor checks the query's `cache` option. If the query cache mode is
+`on`, then not setting this query option or setting it to anything but `false` makes the
+query executor consult the query results cache. If the query cache mode is `demand`, then setting
+the `cache` option to `true` makes the executor look for the query in the query results cache.
+When the query cache mode is `off`, the executor does not look for the query in the cache.
The `cache` attribute can be set as follows via the `db._createStatement()` function:
```js
var stmt = db._createStatement({
query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+ options: {
+ cache: true
+ }
+});
stmt.execute();
```
@@ -186,16 +191,14 @@ stmt.execute();
When using the `db._query()` function, the `cache` attribute can be set as follows:
```js
-db._query({
- query: "FOR doc IN users LIMIT 5 RETURN doc",
- cache: true /* cache attribute set here */
-});
+db._query("FOR doc IN users LIMIT 5 RETURN doc", {}, { cache: true });
```
-The `cache` attribute can be set via the HTTP REST API `POST /_api/cursor`, too.
+You can also set the `cache` query option in the
+[HTTP API](../../develop/http-api/queries/aql-queries.md#create-a-cursor).
-Each query result returned will contain a `cached` attribute. This will be set to `true`
-if the result was retrieved from the query cache, and `false` otherwise. Clients can use
+Each query result returned contain a `cached` attribute. It is set to `true`
+if the result was retrieved from the query results cache, and `false` otherwise. Clients can use
this attribute to check if a specific query was served from the cache or not.
## Query results cache inspection
@@ -207,7 +210,7 @@ The contents of the query results cache can be checked at runtime using the cach
require("@arangodb/aql/cache").toArray();
```
-This will return a list of all query results stored in the current database's query
+This returns a list of all query results stored in the current database's query
results cache.
The query results cache for the current database can be cleared at runtime using the
@@ -221,5 +224,5 @@ require("@arangodb/aql/cache").clear();
Query results that are returned from the query results cache may contain execution statistics
stemming from the initial, uncached query execution. This means for a cached query results,
-the *extra.stats* attribute may contain stale data, especially in terms of the *executionTime*
-and *profile* attribute values.
+the `extra.stats` attribute may contain stale data, especially in terms of the `executionTime`
+and `profile` attribute values.
diff --git a/site/content/3.13/develop/http-api/queries/aql-queries.md b/site/content/3.13/develop/http-api/queries/aql-queries.md
index d51072278..d5479d733 100644
--- a/site/content/3.13/develop/http-api/queries/aql-queries.md
+++ b/site/content/3.13/develop/http-api/queries/aql-queries.md
@@ -577,7 +577,7 @@ paths:
description: |
If set to `true` or `1`, then the additional query profiling information is returned
in the `profile` sub-attribute of the `extra` return attribute, unless the query result
- is served from the query cache. If set to `2`, the query includes execution stats
+ is served from the query results cache. If set to `2`, the query includes execution stats
per query plan node in `stats.nodes` sub-attribute of the `extra` return attribute.
Additionally, the query plan is returned in the `extra.plan` sub-attribute.
type: integer
@@ -1000,10 +1000,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
is returned if the JSON representation is malformed, the query specification is
@@ -1744,10 +1749,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
If the cursor identifier is omitted, the server will respond with *HTTP 404*.
@@ -2381,10 +2391,15 @@ paths:
cached:
description: |
A boolean flag indicating whether the query result was served
- from the query cache or not. If the query result is served from the query
- cache, the `extra` return attribute will not contain any `stats` sub-attribute
- and no `profile` sub-attribute.
+ from the query results cache or not. If the query result is served from the query
+ cache, the `extra` attribute in the response does not contain the `stats`
+ and `profile` sub-attributes.
type: boolean
+ planCacheKey:
+ description: |
+ The key of the plan cache entry. This attribute is only
+ present if a cached query execution plan has been used.
+ type: string
'400':
description: |
If the cursor and the batch identifier are omitted, the server responds with
@@ -3055,6 +3070,21 @@ paths:
type: array
items:
type: string
+ usePlanCache:
+ description: |
+ Set this option to `true` to utilize a cached query plan or add the execution plan
+ of this query to the cache if it's not in the cache yet. Otherwise, the plan cache
+ is bypassed.
+
+ Query plan caching can reduce the total time for processing queries by avoiding
+ to parse, plan, and optimize queries over and over again that effectively have
+ the same execution plan with at most some changes to bind parameter values.
+
+ An error is raised if a query doesn't meet the requirements for plan caching.
+ See [Cache eligibility](../../../aql/execution-and-performance/caching-query-plans.md#cache-eligibility)
+ for details.
+ type: boolean
+ default: false
responses:
'200':
description: |
diff --git a/site/content/3.13/develop/http-api/queries/aql-query-plan-cache.md b/site/content/3.13/develop/http-api/queries/aql-query-plan-cache.md
index 2ee947f77..57706ea4c 100644
--- a/site/content/3.13/develop/http-api/queries/aql-query-plan-cache.md
+++ b/site/content/3.13/develop/http-api/queries/aql-query-plan-cache.md
@@ -51,7 +51,7 @@ paths:
- fullCount
- dataSources
- created
- - numUsed
+ - hits
- memoryUsage
properties:
hash:
@@ -75,7 +75,8 @@ paths:
fullCount:
description: |
The value of the `fullCount` query option in the
- original query.
+ original query. This option generally leads to different
+ execution plans.
type: boolean
dataSources:
description: |
@@ -89,7 +90,7 @@ paths:
to the cache (in ISO 8601 format).
type: string
format: date-time
- numUsed:
+ hits:
description: |
How many times the cached plan has been utilized so far.
type: integer
@@ -102,7 +103,30 @@ paths:
- Queries
```
-## Clear the AQL query results cache
+```curl
+---
+name: HttpListQueryPlanCache
+description: |
+ Retrieve the entries stored in the AQL query plan cache of the current database:
+---
+db._create("coll");
+for (let i = 0; i < 3; i++) {
+ db._query("FOR doc IN @@coll FILTER doc.attr == @val RETURN doc", {
+ "@coll": "coll", val: "foo"
+ }, { usePlanCache: true });
+}
+db._query("RETURN 42", {}, { usePlanCache: true });
+
+var url = "/_api/query-plan-cache";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.length >= 2);
+logJsonResponse(response);
+
+db._drop("coll");
+```
+
+## Clear the AQL query plan cache
```openapi
paths:
@@ -147,4 +171,16 @@ paths:
example: 200
tags:
- Queries
-```
\ No newline at end of file
+```
+
+```curl
+---
+name: HttpClearQueryPlanCache
+description: |
+ Clear the AQL query plan cache of the current database:
+---
+var url = "/_api/query-plan-cache";
+var response = logCurlRequest('DELETE', url);
+assert(response.code === 200);
+logJsonResponse(response);
+```
diff --git a/site/content/3.13/develop/http-api/queries/aql-query-results-cache.md b/site/content/3.13/develop/http-api/queries/aql-query-results-cache.md
index 9c0832999..77325280a 100644
--- a/site/content/3.13/develop/http-api/queries/aql-query-results-cache.md
+++ b/site/content/3.13/develop/http-api/queries/aql-query-results-cache.md
@@ -5,6 +5,14 @@ weight: 10
description: >-
The query results cache HTTP API lets you control the cache for AQL query results
---
+See [The AQL query results cache](../../../aql/execution-and-performance/caching-query-results.md)
+for a description of the feature and the configuration options.
+
+{{< info >}}
+The AQL query results cache is only available for single servers, i.e. servers that
+are not part of a cluster setup.
+{{< /info >}}
+
## List the entries of the AQL query results cache
```openapi
@@ -14,20 +22,7 @@ paths:
operationId: listQueryCacheResults
description: |
Returns an array containing the AQL query results currently stored in the query results
- cache of the selected database. Each result is a JSON object with the following attributes:
-
- - `hash`: the query result's hash
- - `query`: the query string
- - `bindVars`: the query's bind parameters. this attribute is only shown if tracking for
- bind variables was enabled at server start
- - `size`: the size of the query result and bind parameters, in bytes
- - `results`: number of documents/rows in the query result
- - `started`: the date and time when the query was stored in the cache
- - `hits`: number of times the result was served from the cache (can be
- `0` for queries that were only stored in the cache but were never accessed
- again afterwards)
- - `runTime`: the query's run time
- - `dataSources`: an array of collections/Views the query was using
+ cache of the selected database.
parameters:
- name: database-name
in: path
@@ -40,14 +35,103 @@ paths:
responses:
'200':
description: |
- Is returned when the list of results can be retrieved successfully.
+ The list of cached query results.
+ content:
+ application/json:
+ schema:
+ description: |
+ The entries of the query results cache.
+ type: array
+ items:
+ description: |
+ The properties of a cache entry.
+ type: object
+ required:
+ - hash
+ - query
+ - size
+ - results
+ - hits
+ - runTime
+ - started
+ - dataSources
+ properties:
+ hash:
+ description: |
+ The hash value calculated from the the query string,
+ certain query options, and the bind variables.
+ type: string
+ query:
+ description: |
+ The query string.
+ type: string
+ bindVars:
+ description: |
+ The bind parameters. This attribute is omitted if the
+ `--query.tracking-with-bindvars` startup option is set
+ to `false`.
+ type: object
+ size:
+ description: |
+ The size of the query result and bind parameters (in bytes).
+ type: integer
+ results:
+ description: |
+ The number of documents/rows in the query result.
+ type: integer
+ started:
+ description: |
+ The date and time at which the query result has been added
+ to the cache (in ISO 8601 format).
+ type: string
+ format: date-time
+ hits:
+ description: |
+ How many times the result has been served from the cache so far.
+ type: integer
+ runTime:
+ description: |
+ The total duration of the query in seconds.
+ type: number
+ dataSources:
+ description: |
+ The collections and Views involved in the query.
+ type: array
+ items:
+ type: string
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpListQueryResultsCache
+description: |
+ Retrieve the entries stored in the AQL query results cache of the current database:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+db._create("coll");
+for (let i = 0; i < 3; i++) {
+ db._query("FOR doc IN @@coll FILTER doc.attr == @val RETURN doc", {
+ "@coll": "coll", val: "foo"
+ }, { cache: true, fullCount: true });
+}
+db._query("RETURN 42", {}, { cache: true });
+
+var url = "/_api/query-cache/entries";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.length >= 2);
+logJsonResponse(response);
+
+db._drop("coll");
+```
+
## Clear the AQL query results cache
```openapi
@@ -69,15 +153,44 @@ paths:
responses:
'200':
description: |
- The server will respond with *HTTP 200* when the cache was cleared
- successfully.
+ The results cache has been cleared.
+ content:
+ application/json:
+ schema:
+ type: object
+ required:
+ - error
+ - code
+ properties:
+ error:
+ description: |
+ A flag indicating that no error occurred.
+ type: boolean
+ example: false
+ code:
+ description: |
+ The HTTP response status code.
+ type: integer
+ example: 200
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request.
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpClearQueryResultsCache
+description: |
+ Clear the AQL query results cache of the current database:
+---
+var url = "/_api/query-cache";
+var response = logCurlRequest('DELETE', url);
+assert(response.code === 200);
+logJsonResponse(response);
+```
+
## Get the AQL query results cache configuration
```openapi
@@ -86,23 +199,7 @@ paths:
get:
operationId: getQueryCacheProperties
description: |
- Returns the global AQL query results cache configuration. The configuration is a
- JSON object with the following properties:
-
- - `mode`: the mode the AQL query results cache operates in. The mode is one of the following
- values: `off`, `on`, or `demand`.
-
- - `maxResults`: the maximum number of query results that will be stored per database-specific
- cache.
-
- - `maxResultsSize`: the maximum cumulated size of query results that will be stored per
- database-specific cache.
-
- - `maxEntrySize`: the maximum individual result size of queries that will be stored per
- database-specific cache.
-
- - `includeSystem`: whether or not results of queries that involve system collections will be
- stored in the query results cache.
+ Returns the global AQL query results cache configuration.
parameters:
- name: database-name
in: path
@@ -117,14 +214,62 @@ paths:
responses:
'200':
description: |
- Is returned if the properties can be retrieved successfully.
+ The result cache configuration is returned successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+```curl
+---
+name: HttpGetQueryResultsCacheProperties
+description: |
+ Retrieve the global configuration of the AQL query results cache:
+---
+var resultsCache = require("@arangodb/aql/cache");
+resultsCache.properties({ mode: "demand" });
+
+var url = "/_api/query-cache/properties";
+var response = logCurlRequest('GET', url);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+logJsonResponse(response);
+```
+
## Set the AQL query results cache configuration
```openapi
@@ -135,14 +280,7 @@ paths:
description: |
Adjusts the global properties for the AQL query results cache.
- After the properties have been changed, the current set of properties will
- be returned in the HTTP response.
-
- Note: changing the properties may invalidate all results in the cache.
-
- The properties need to be passed in the `properties` attribute in the body
- of the HTTP request. `properties` needs to be a JSON object with the following
- properties:
+ Changing the properties may invalidate all results currently in the cache.
parameters:
- name: database-name
in: path
@@ -158,35 +296,90 @@ paths:
content:
application/json:
schema:
+ description: |
+ The result cache configuration settings to change.
type: object
properties:
mode:
description: |
- the mode the AQL query cache should operate in. Possible values are `off`, `on`, or `demand`.
+ The mode the AQL query cache shall operate in.
type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
maxResults:
description: |
- the maximum number of query results that will be stored per database-specific cache.
+ The maximum number of query results that are stored per
+ database-specific cache.
type: integer
maxResultsSize:
description: |
- the maximum cumulated size of query results that will be stored per database-specific cache.
+ The maximum cumulated size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
maxEntrySize:
description: |
- the maximum individual size of query results that will be stored per database-specific cache.
+ The maximum individual size of query results that are stored
+ per database-specific cache (in bytes).
type: integer
includeSystem:
description: |
- whether or not to store results of queries that involve system collections.
+ Whether to store results of queries that involve
+ system collections in the cache.
type: boolean
responses:
'200':
description: |
- Is returned if the properties were changed successfully.
+ The result cache configuration has been changed successfully.
+ content:
+ application/json:
+ schema:
+ description: |
+ The result cache configuration.
+ type: object
+ properties:
+ mode:
+ description: |
+ The mode the AQL query results cache operates in.
+ type: string
+ # Unquoted on and off are booleans in YAML 1.1!
+ enum: ["off", "on", "demand"]
+ maxResults:
+ description: |
+ The maximum number of query results that are stored per
+ database-specific cache.
+ type: integer
+ maxResultsSize:
+ description: |
+ The maximum cumulated size of query results that are
+ stored per database-specific cache (in bytes).
+ type: integer
+ maxEntrySize:
+ description: |
+ The maximum individual result size of queries that are
+ stored per database-specific cache (in bytes).
+ includeSystem:
+ description: |
+ Whether results of queries that involve system collections
+ are stored in the query results cache.
+ type: boolean
'400':
description: |
- The server will respond with *HTTP 400* in case of a malformed request,
+ The request is malformed.
tags:
- Queries
```
+
+```curl
+---
+name: HttpSetQueryResultsCacheProperties
+description: |
+ Change some properties of the global configuration of the AQL query results cache:
+---
+var url = "/_api/query-cache/properties";
+var body = { mode: "demand", maxResults: 32 };
+var response = logCurlRequest('PUT', url, body);
+assert(response.code === 200);
+assert(response.parsedBody.mode == "demand");
+assert(response.parsedBody.maxResults == 32);
+logJsonResponse(response);
+```
diff --git a/site/content/3.13/release-notes/version-3.12/api-changes-in-3-12.md b/site/content/3.13/release-notes/version-3.12/api-changes-in-3-12.md
index 24c0cfc24..83375279d 100644
--- a/site/content/3.13/release-notes/version-3.12/api-changes-in-3-12.md
+++ b/site/content/3.13/release-notes/version-3.12/api-changes-in-3-12.md
@@ -353,6 +353,29 @@ Two new statistics are included in the response when you execute an AQL query:
}
```
+#### Query plan cache attributes
+
+Introduced in: v3.12.4
+
+The following endpoints related to AQL queries support a new `usePlanCache`
+query option in the `options` object:
+
+- `POST /_api/cursor`
+- `POST /_api/explain`
+
+An error is raised if `usePlanCache` is set to `true` but the query is not
+eligible for plan caching (a new error code
+`ERROR_QUERY_NOT_ELIGIBLE_FOR_PLAN_CACHING` with the number `1584`). See
+[The execution plan cache for AQL queries](../../aql/execution-and-performance/caching-query-plans.md)
+for details.
+
+If a cached query plan is utilized, the above endpoints include a new
+`planCacheKey` attribute at the top-level of the response with the key of the
+cached plan (string).
+
+See [HTTP interfaces for AQL queries](../../develop/http-api/queries/aql-queries.md#cursors)
+for details.
+
#### Index API
##### `optimizeTopK` for inverted indexes
diff --git a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md
index 0aa5ee0c4..c04fefa8c 100644
--- a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md
+++ b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md
@@ -1016,7 +1016,7 @@ require("@arangodb/aql/plan-cache").toArray();
"coll"
],
"created" : "2024-11-20T17:21:34Z",
- "numUsed" : 0,
+ "hits" : 0,
"memoryUsage" : 3070
}
]