# Inspect the chosen query plan

An optimizer label does not tell you which access path a particular Coordinator DB query will use. Inspect the documented plan output for the exact predicate, schema and representative input data.

```sql
CREATE TABLE plan_items(id INTEGER PRIMARY KEY, category TEXT, price INTEGER);
CREATE INDEX plan_items_by_category ON plan_items(category);

EXPLAIN QUERY PLAN
SELECT id, price FROM plan_items WHERE category = 'books';
```

The plan is evidence about this statement. It is not a promise that an index will be selected for every category, table size or differently written predicate. A primary-key equality lookup and a grouped scan can require very different work.

Use `EXPLAIN ANALYZE` when an executed measurement is needed. It runs the statement once and returns measured plan information instead of the original rows. For data-changing statements, those changes take effect unless rolled back in an appropriate transaction.

Compare equivalent results, keep the input data stable and record the query ID for terminal request counters. Do not describe undocumented optimizer statistics, cost formulas or tuning commands as supported APIs. A useful performance decision should be justified by the selected plan and actual reader workload.

See [`EXPLAIN`](https://coordinatordb.com/docs/reference/statements/explain), [index definitions](https://coordinatordb.com/docs/reference/statements/create/create-index) and [measurement comparisons](https://coordinatordb.com/docs/resources/support-center/knowledge-base/queries-sql/comparing-metrics-between-queries).