mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-12 23:02:28 +00:00
Jack Ye
734eb39dc3
Six groups were verbs -- Manage, Ingest, Train, Operate, Secure, Deploy -- and now name the thing rather than the action. Four more were sentence case. The page labels that were verb phrases follow: Add Computed Column becomes Computed Columns, Refresh Column becomes Column Refresh, Configuring Storage becomes Configuration, and Explain becomes Query Plans, which is also more accurate now that the page covers analyze as well. SQL statement pages take the keyword -- SELECT, DDL, DML, REFRESH, SHOW, EXPLAIN -- because a statement name is a noun and lowercase Select and Show read as instructions. Concept pages there keep noun phrases: Joins, Window Functions, Subqueries, Operators. Two duplicate labels are resolved on the way. Reranking sat in Semantic Search labelled Overview despite being the only page on its subject, and the Enterprise client page sat in SQL Reference labelled SQL next to the reference Overview; it is Client Connection now. Title case leaves prepositions and articles lowercase, so Needle in a Haystack and Hybrid Search on BEIR are already correct and unchanged.
52 lines
1.6 KiB
Plaintext
52 lines
1.6 KiB
Plaintext
---
|
|
title: "EXPLAIN"
|
|
sidebarTitle: "EXPLAIN"
|
|
description: "Reading the plan for a statement, and measuring it."
|
|
icon: map
|
|
keywords: ["explain", "explain analyze", "query plan", "describe"]
|
|
---
|
|
|
|
<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
|
|
```
|
|
|
|
`EXPLAIN` resolves the plan without running the query. `EXPLAIN ANALYZE`
|
|
executes it and annotates every operator with runtime metrics — elapsed time,
|
|
rows produced, bytes read, index comparisons.
|
|
|
|
The operators are the same ones the SDK methods produce, so the reasoning about
|
|
index coverage and filter pushdown carries across unchanged. The two pages that
|
|
explain how to read them:
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Explain" icon="map" href="/search/explain">
|
|
Reading a plan: operators, pushdown, index usage.
|
|
</Card>
|
|
<Card title="Explain Analyze" icon="gauge" href="/search/explain">
|
|
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/join#performance).
|
|
|
|
## DESCRIBE {#describe}
|
|
|
|
```sql
|
|
DESCRIBE documents
|
|
```
|
|
|
|
The table's columns and types, without a plan.
|