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

Responses

• 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"
}

Loading...