# Measure query processing time

A stopwatch around an HTTP or native-client call measures connection setup, authentication, SQL processing and delivery of the result. Use the request's recorded measurements when you need to investigate processing rather than the full client journey.

## Record the request

HTTP responses include `X-Coordinator-Query-Id` and `X-Coordinator-Summary`. Save these alongside the client's elapsed time. The summary includes `elapsed_ms`, result rows, read and write counters, and memory measurements. Native requests also appear in structured query history when logging is enabled.

```sql
SELECT query_id, query_duration_ms, result_rows
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY event_time DESC
LIMIT 10
FORMAT csv;
```

Query history is asynchronous; a direct single-table query waits for previously queued events. The observing request's own terminal event appears only after it finishes.

## Avoid misleading comparisons

Use the same SQL, data and output format for repeated measurements. A large CSV response and a single aggregate row have different delivery costs. `EXPLAIN ANALYZE` executes the statement once and reports runtime measurements without returning its ordinary rows; analyzed writes still change data.

See [HTTP response metadata](https://coordinatordb.com/docs/concepts/features/interfaces/http), [EXPLAIN](https://coordinatordb.com/docs/reference/statements/explain) and [system.query_log](https://coordinatordb.com/docs/reference/system-tables/query-log).
