Explain the search execution plan

POST 
/graph/:graph_id/search/explain

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)

Request

Path Parameters

graph_id stringrequired
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.

at date-time

The timestamp to use for the search. If not defined the latest version of the graph is used.

text/plain

Body

The search to perform

string

Responses

200

The execution plan of the database

application/json

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.

Example (from schema)

{
  "estimated_cost": 0,
  "estimated_nr_items": 0,
  "available_nr_items": 0,
  "full_collection_scan": true,
  "rating": "simple"
}

Loading...