a5a25754ed
* reduce extractions to projections * recycle string buffers in SocketTask * micro optimizations for mmfiles indexes * added special lookup function for _key * moved function into the correct file * speed up key buffer allocations a bit * added noexcept specifier * correctly name variable * explicitly move bounds * fix and speedup from/toPersistent functions * reuse string from ManagedDocumentResult for multiple lookups * use move-assign * a bit less work for single server * speedup AQL function HASH * single fetch optimization * performance optimization for the case when no documents need to be returned * make reduce-extraction-to-projection a RocksDB-only optimizer rule * cppcheck * try to fix compile error on MacOS * bug fix for MacOSX * missing namespace (in Windows compile) |
||
|---|---|---|
| .. | ||
| ExplainingQueries.md | ||
| Optimizer.md | ||
| ParsingQueries.md | ||
| QueryCache.md | ||
| QueryStatistics.md | ||
| README.md | ||
README.md
AQL Execution and Performance
This chapter describes AQL features related to query executions and query performance.
-
Execution statistics: A query that has been executed also returns statistics about its execution.
-
Query parsing: Clients can use ArangoDB to check if a given AQL query is syntactically valid.
-
Query execution plan: If it is unclear how a given query will perform, clients can retrieve a query's execution plan from the AQL query optimizer without actually executing the query; this is called explaining.
-
The AQL query optimizer: AQL queries are sent through an optimizer before execution. The task of the optimizer is to create an initial execution plan for the query, look for optimization opportunities and apply them.
-
The AQL query result cache: an optional query result cache is used to avoid repeated calculation of the same query results.