Explain the search execution plan​
Explain the runtime characteristics of a search without performing the search. A section can be defined (defaults to /
== root) to interpret relative property paths. Example: is(volume) and (reported.age>23d or desired.clean==true or metadata.version==2)
Path Parameters
- graph_id string required
The identifier of the graph
Example: resoto
Query Parameters
- section string
Possible values: [
reported
,desired
,metadata
]The name of the section used for all property paths. If not defined root is assumed.
- text/plain
Request Body
The search to perform
- string
- 200
The execution plan of the database
- application/json
- Schema
- Example (from schema)
Schema
- estimated_cost integer
Absolute number that shows the cost of this search. See rating for an interpreted number.
- estimated_nr_items integer
This is the estimated number of items returned for this search. Please note: it is computed based on search statistics and heuristics and does not reflect the real number.
- available_nr_items integer
This is the number of available nodes in the graph.
- full_collection_scan boolean
Indicates, if a full collection scan is required. This means, that the search does not take advantage of any indexes!
- rating string
Possible values: [
simple
,complex
,bad
]The rating of this search. A simple search is usually fine. A complex search might be acceptable in certain cases. Maybe an index can be used to make this search simple? A bad search is usually something where an index is missing or the search has to be rewritten.
{
"estimated_cost": 0,
"estimated_nr_items": 0,
"available_nr_items": 0,
"full_collection_scan": true,
"rating": "simple"
}