mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-12 23:02:28 +00:00
Jack Ye
52684d50b9
OSS docs now own the full usage content for features that only run against an Enterprise deployment, since the client interface itself lives here; Enterprise docs keep only the parts specific to its own behavior. Sophon's overlay for these five pages is dropped since the OSS versions are now the complete reference. SQL Reference is restructured to match an object-type SQL manual (DDL by object, then DML, then DQL, then Expressions) instead of the old flat, loosely-ordered page list, absorbing the SQL client-connection guide and FTS-via-SQL examples into it.
53 lines
2.0 KiB
Plaintext
53 lines
2.0 KiB
Plaintext
---
|
|
title: "Explain"
|
|
sidebarTitle: "Explain"
|
|
description: "EXPLAIN, EXPLAIN ANALYZE and EXPLAIN VERBOSE — reading and measuring a plan from SQL."
|
|
icon: map
|
|
keywords: ["explain", "explain analyze", "explain verbose", "query plan"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
|
|
|
|
```sql
|
|
EXPLAIN SELECT * FROM documents WHERE identifier < 1000
|
|
EXPLAIN ANALYZE SELECT * FROM documents WHERE identifier < 1000
|
|
```
|
|
|
|
| Statement | What it returns |
|
|
| --- | --- |
|
|
| `EXPLAIN <query>` | Logical and physical plan, without executing the query. |
|
|
| `EXPLAIN ANALYZE <query>` | Executes the query and annotates each operator with runtime metrics (rows, timing). |
|
|
| `EXPLAIN VERBOSE <query>` | Adds intermediate optimizer plans on top of `EXPLAIN`. |
|
|
|
|
The result is a small relation with `plan_type` and `plan` columns, read
|
|
through the same client you use for regular queries -- see
|
|
[Connecting](/sql#connecting).
|
|
|
|
The operators are the same ones the SDK's
|
|
[`explain_plan` and `analyze_plan`](/search/explain) methods produce, so the
|
|
reasoning about index coverage and filter pushdown carries across unchanged:
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="What it shows" icon="map" href="/search/explain#inspect-a-query-plan">
|
|
Reading a plan: operators, pushdown, index usage.
|
|
</Card>
|
|
<Card title="What it measures" icon="gauge" href="/search/explain#analyze-a-query-plan">
|
|
Reading the metrics, and a worked before/after.
|
|
</Card>
|
|
</CardGroup>
|
|
|
|
## What to look for {#what-to-look-for}
|
|
|
|
| Sign | Means |
|
|
| --- | --- |
|
|
| `ScalarIndexQuery` | the predicate used a scalar index |
|
|
| `LanceScan` with high `bytes_read` | no index, or too many columns selected |
|
|
| `FilterExec` above a search | the filter ran after search rather than pushing into it |
|
|
| `ANNSubIndex` / `ANNIvfPartition` | the vector index was used |
|
|
|
|
A `LanceScan` feeding a join is the common one worth acting on -- see
|
|
[Joins](/sql/dql/join#performance).
|
|
|
|
For a table's columns and types without a plan, see
|
|
[`DESCRIBE`](/sql/ddl/table#describe).
|